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 Mercurial.

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

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 push my release branch to the central mirror and then fetch the remote master and merge it into my master.
• 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 when I merge the remote master into my master the merge should be a fast-forward. This is because I never commit into my own master -- only pull into it.

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 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.