What are some of the most common Git branching schemes/commit lifecycles?

Question

First off, sorry if this is a duplicate, but I tried searching and all I could find was stuff on how to make branches in Git and whatnot. That's not what I'm looking for so much; I'm trying to figure out how different people out there setup their Git branches to match their workflow.

Let me give you an example of how our company does it:

1. Developer commits to their own branch, locally
2. Developer pushes commit to their remote, where a continuous build system checks it and another developer reviews it
3. If the review/build passes, the commit is merged in to a QA branch (if it fails, more commits are made until the review/build passes)
4. If the commit fails QA, a revert commit is made to get it out
5. After enough QA commits are ready, our master branch gets the commits (the QA branch is based off it so no merges are needed)
6. Periodically branches are taken from the master branch, and used to release "in to the wild". If problems are found here, a revert commit will again be used to remove the code
7. After a release, developers rebase their branches on to the master branch (getting both their previous commits and those of other developers)

Now, there are some problems with this system; I'll note a few in the comments, but I'm not really looking for "please fix our system for me", I'm just trying to see what other branching options we could be using instead, so that I can weigh the various possibilities.

So, if you have worked at multiple companies that use Git (or even better, if you're some kind of consultant who has seen tons of Git setups), could you please share: how do different companies setup Git branches (and move commits between them) to facilitate the various stages of development ... all while trying to be as minimally annoying as possible? I'm sure there must be some common patterns ... but I have no idea what they are.

P.S. If you've only seen one Git setup, but you think it's interesting, by all means please post it. However, I'd like to award the answer to whoever provides the best breakdown of possible options, and I expect that would come from someone who has seen several Git setups.

Answer 1

What about this (I'm ignoring what the developers have on their machine):

• each developer has a accepted patches branch (QA commits here), that is based from the last master checkpoint (new branch for each release)
• each developer has a pending patches branch he commits into that is continuously rebased against the accepted patches branch (persistent branch)
• once QA is done for all developers, all accepted patches branches are merged into master
• new QA branches are created and all developers rebase again

Answer 2

"After a release, developers rebase their branches": ouch...

I am not a Git consultant (yet), but by experience, developers ought to rebase their work much more often (than only "just after a release").
Otherwise, like you mention in your comment, that leads to lots of "git revert" (which works, but should remain an exceptional occurrence rather than a common fix).

Peer to peer collaboration is possible but nvolve a bit of discipline as it requires setting up a bare repo and local protocol.

Answer 3

I've been managing several teams now that are using Git and we have evolved a strategy that works very well for us.

• Master is ALWAYS a copy of EXACTLY what is in production. When the code gets released, the current branch gets fast-forwarded to master, and a tag is added so the release is marked in time and we can grab the code if we ever need to.
• Developers have the freedom to work how they please as far as THEIR branches go, however for feature branches, we usually have one branch for each feature and multiple developers merge to and from that branch to share in the work on that feature.
• When its time for a release candidate, an RC_XXX branch is created, and feature branches that are far enough along are all merged into it. This is then tested, and bug fixes are branched off of this.
• When all is said and done, the RC_XXX branch gets released to production, and after it "sticks" for a few days, we promote it to master and new feature branches are then based off of it.

This works very well, as hot fixes against production are easy to create and deploy by just branching off master, and developers can branch against the feature branches to pull in dependencies if necessary.