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

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 2

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.