What team workflow processes do you use concerning git?

Question

I am in the process of moving my team from TFS to GIT in the very near future, but before I do so I want to know about any pitfalls that others may have experienced when moving a team from a centralized source control such as CVS, SVN, TFS, etc to a distributed source control system like GIT or Mecurial.

Some questions that instantly came time mind are:

1. Does each user work of their own branch on the server and then merge in when done, or do they just stay local to their machines and push to the server when done?

2. Should all new development work be done on a branch (i.e. "next-version") or should it be done against "master"?

3. Should new development be done in a clone on the server, and then issue pull requests to the production code base, or is a branch of the production code base good enough?

4. Follow up to number 3, if everything is done on a branch is there anyway to control who can do merges in to "master"?

5. Is there anything else I should worry about that I am not thinking of that happened in your move from centralized version control to distributed version control?

However my real curiosity and question concerns how you manage your workflow processes concerning GIT and other distributed source control systems, not really something that fits my current workflow process.

Update: Currently the development process in TFS is we have a master folder and then a branch folder for the next-version stuff, and when the next-version code is finished it is merged back in to the master folder. Each member of the team has full commit rights to the whole project. We don't have a sophisticated process by any stretch of imagination, we have up until now used our source control as just a dumb repository.

However that being said, I am looking for more of an ideal situation workflow process, not really something that fits my current workflow. That is is why I titled the question What team workflow processes do __you__ use concerning GIT?

Answer 1

Git shapes towards your need, not the other way around (as it is with centralized source control systems).

If you tell us how you manage your development and releases, we can tell you what workflow in GIT would suit that.

Edit: As for the update, you can easily do this workflow in git. The question is what more do you want from the source management tool. Making a change just because we want a change is not a very good idea.

Answer 2

Note that I haven't used Git in a corporate setting, and answers below are based on my experience with working on OSS projects with Git, and my understanding of Git.

See also gitworkflows(7) manpage.

• Does each user work of their own branch on the server and then merge in when done, or do they just stay local to their machines and push to the server when done?

In any distributed version control system, and in any workflow utilizing DVCS, each user has its own private repository, non-bare, in which he or she dows his/her work. The common practice is that user do not publish his/her work until it is ready.

Publishing one's work might mean pushing to some central repository, or it can mean pushing to one's own public repository; from this developer's public repository the maintainer (or equivalent) can pull changes.

Check out nice description (with diagrams!) of possible workflows in Chapter 5.1: Distributed Workflows of Pro Git. Proffesional Version Control CC-licensed book by Scott Chacon.

• Should all new development work be done on a branch (i.e. "next-version") or should it be done against "master"?

The recommended workflow (but certainly not the only one possible) is to develop each separate feature on separate branch, so called feature branches. When feature is considered ready, it is merged into 'next' (development branch) or into 'master' (stable branch).

[...]

• Is there anything else I should worry about that I am not thinking of that happened in your move from centralized version control to distributed version control?

If you have large and often changing binary files, then working with distributed version control system might be harder to setup; then centralized version control system might be better.

Answer 3

From your questions I feel your mindset is still that of a centralized version control system. In a distributed system the server is no longer a "workplace", but a mere mirror of the collective work. As such, it's not even strictly necessary.

Usually the central repository has nothing but the master branch and the release tags. It should only mirror everyone's common factor. Branches in a distributed system are very private, and so should stay local.

In my work on my private repository I have the following branches:

• master is an exact reflection of the central master. I never ever commit into it. Instead, I only pull from the central mirror into my master.
• develop-* are a set of feature (work) branches that branch off from the release branch. For example, I might have a branch named develop-foo_performance where I tune class Foo's performance. Or, I might have a branch called develop-cosmetics where I accumulate some minor cosmetics commits. These are mostly short-lived branches for very specific tasks. These are draft branches; I commit here all the time, free-writing the commit messages and without giving a moment's thought about "whether this change is worthy of a commit". It's my private mistakes-hiding history-tracking Ctrl-S.
• release is the branch into which I squash commits ready for publishing. When I'm done coding my specific idea for the performance tune-up for Foo on branch develop-foo_performance I am likely to have a set of disorganized commits, experimenting in various directions. I rebase these commits into the release branch, squashing them into logical feature-oriented commits -- often a single commit. This squash throws away all the code that didn't end up in the final state, so the history that release shows is very clean and linear; all the experimenting is gone, as if I'm a perfect developer than can see into the future, never makes a mistake and has awesomely descriptive commits. At the end of the day I merge (not rebase!) master and then push my release branch to the central mirror.
• napkin is my personal notes branch. Its root commit is distinct from that of master. I never ever merge or rebase this branch into any other, never push it or pull into it, never merge anything in here. Here I store my todo file, bugs I find, my personal notes, ideas, questions for pondering, or any other free-writing documents. It's a disjoint branch and it's for my personal way of doing things: no one ever sees it. It keeps me organized and clear.

For any and every project I have, whether at work or at home, these are the only branches I have. I only create new develop-* branches and delete complete and failed ones. The other branches never die and never rebase. Note that if I'd rebase release onto master instead of merging master into release then it would pull off the rug from the develop-* branches' feet. It's a headache to resolve the conflicts then. Worse yet, release is the branch I publish to the central master, so rebasing it can pull off the rug from other people's feet.

This workflow supports an integration developer; a developer that is in charge of integrating other people's work into the central master branch. If people never commit into their personal master branch then they have the guarantee that their personal master looks exactly the same as that of the production codebase. It's a safety net of a sort, so people can always branch off from it if they need a clean-slate codebase.

If two developers want to share on an experiment then they can send each other pull requests, or send commits by email with git format-patch. This is distributed work at its finest: the communication is between peers, and people who don't care about the experiment don't have to see it. They stay focused and the project looks smaller and simpler for them.

Answer 4

I made use of this work flow where in our organization: http://nvie.com/posts/a-successful-git-branching-model/

We set up management of who can do what to what branch through gitolite.

It has been a good "tail light to follow through the fog". With endless options that Git gives you, it's hard to make the decision for yourself as to what your work flow should be. Start with this one and adapt. It worked for us really well. We are using the .net stack with an OSS flavour (NHibernate, etc)

Hope this helps,

Adam