Git Workflow and Release Branches: Many, One, or None?

Question

For our web development, we have daily to weekly deployments. There are instances where we deploy something to QA, but they don't get around to testing it for a few days, and then we have a production fix or a new enhancement that needs to go out. Two questions:

(1) What would be a good workflow for this?

(2) What are the advantages and disadvantages to having one continuous, long lived branch called production or release, as opposed to a new release branch for each release, or just doing everything out of master and tagging it accordingly? Again, this is for web development with frequent releases that can get backed-up.

Answer 1

I'm not quite sure I understand your problem correctly, but my situation is similar to yours and I used (modification of) the following approach: http://nvie.com/posts/a-successful-git-branching-model/

In short, it's about having 2 main branches ( master and develop ) and several types of supporting branches ( feature , release and hotfix ones). Speaking about your case, you would probably deploy to QA your release branches and then when you have a production fix, you would do it in a hotfix branch and then merge it to both - master and release branches.

As for your second question... well, you know, there are so many different opinions about branching strategies out there ( example ...) I would say, continuous production branch works great (and it doesn't mean you can't have release branches to support your workflow).

Answer 2

At my previous job, we used a similar approach to what @Alexis mentioned, with one main difference. Keep in mind we were working on a new version of some pretty major legacy software (our codebase was several million lines of code, between Java, flex and COBOL) and had a customer partner beta testing for us. Releases were bi-/weekly, including to the customer (though they would typically be one release behind latest, as that one would go through QA first), and in that week we had to do a 'cut', test, basic QA by the client of our code, which was another developer in the company, and then release to real QA.

Essentially, master was our dev branch. If a dev item was to take more than a day or two, it was completed on a feature branch and then merged into dev when ready. There was another 'future' dev branch that was reserved for fairly serious new feature work (anything that changed the program in a significant way), or major refactoring. At some point this would become main 'dev' when we decided that we had time to properly test and iron out bugs, or that it was time to introduce the new features and deal with the inevitable pain :)

When it was time for a release, a new branch was created called 'release_x', then all fixes that came from QA were implemented there and merged 'up'. By that I mean that we could have two or three versions in play at any one time, so the customer would obviously have the oldest which we might do a fix for if they found a showstopper. This would be done on a hotfix branch coming off the relevant release, which at some point would be merged into that release and deleted (so you could easily see outstanding hotfixes in a branch list) and another build done and sent to the customer. The 'hotfix' branches existed so that we could pick and choose what went into a particular build, which functioned for the customer release as well as the developer release, to avoid potentially risky fixes for small issues upsetting the release of a fix for a showstopper.

That would then be merged up to the release that the QA guys had, then that would be merged to the release the other developers were using (always the latest release due to their reliance on our plugins and j2ee infrastructure to do their work), then back into dev, just to keep everything on the level.

All of the releases currently in play had their own automated build loop in Jenkins, as well as the dev branch, with some automated functional tests running on the more important ones (dev and QA mainly). Each build added a tag to the report on the commit that was used as HEAD, and the build number was available from the program so that we could see exactly which version the bug reporter was using.

So essentially, two dev branches, one of them for major work to be released later as a new major version. Release branches for each release, with hotfix branches coming off those. Finding the latest release was an easy matter, look for the release branch with the biggest number.

The only downside was that if you did many fixes at a release several versions back, then the merging graphs were... interesting to follow :)

Answer 3

You should definitely

• make release branches
• put in it the fixes you made after QA feedback
• merge them back to master.

That's a natural and efficient workflow.

Answer 4

We have used Gitflow workflow branching model which is derived from Vincent Driessen at nvie as Alexis mentioned above.

The idea is that you will have two main branches Develop and Master. Developers may have their own feature branches which eventually get merged back into Develop once the feature is ready. When the development is finished on a feature, you fork a release branch off of Develop which starts your release cycle. Testing will be done on this branch and if any bugs are introduced as a result they will also be fixed on this branch but no new features will be added to this branch. Once everyone is happy with the release it gets merged into Master and tagged with a version number. You also merge it back into Develop.

If a bug is found in the production code, you fork a new Hotfix branch off of Master. As soon as the fix is complete you merge Hotfix into Master. If the Hotfix was created during the release cycle you would merge it into Release otherwise into Develop.

without hotfix:

Feature -> Develop <=> Release -> Master

with hotfix during the release cycle:

Feature -> Develop <=> Release <- Hotfix <=> Master '

with hotfix after the release cycle:

Feature -> Develop <- Hotfix <=> Master '