Git Branching Strategies That I've Used

I've used two different branching strategies for Git at previous jobs. Each had their own advantages and disadvantages.

Job #1 - Testable Master Branch, Single Development Branch, Tags for Releases

My memory is a little fuzzy on this workflow, but I think that a previous employer's workflow went something like this:

1. Use a central development branch for all development
2. Push ready-to-test increments to master
3. Tag each release

At this job, I worked with the company's QA team and developers on my team to create a Git workflow that would work for everyone. We used an iterative development process where QA would typically test after the development increment. This required a workflow that did the following:

• Have separate branches for in-development and ready-to-test changes
• Allow QA to quickly access ready-to-test code
• Have a history of releases
• Allow access to code via automated tooling

I'm not sure how it happened, but we had some long meetings on it and decided to have developers work off of the development branch. It worked quite well. QA was able to easily identify, access, and test ready-to-test features, and developers could work from development and merge into master for increments and hot fixes

This Git workflow was used for development of a white-label application. I built a custom website that would, among many other things, commit new variants of the white-label app to source control. It helped to have master contain a potentially releasable code base. If there was a branch for each release, the website would need to be manually updated to use each release branch, and someone would have to merge variant additions back into master/development. Using tags for releases was a great decision because my site could pull from master and I didn't have to worry about what version was being built at any given time.

All users of the application used the latest in-production version of the application. Because of this, there wasn't much of a need to go back to old versions of the code base. I don't see the approach working very well for teams that support multiple versions of the same application, but the workflow was great for what we needed it for.

Job #2 - Development on Master Branch, Branch on Release

At a different job, my team was among the last in the company to use Git for source control. As a result, my project inherited a Git workflow that the rest of the company had already implemented, and this ended up being the mirror image of the previous workflow:

1. Use master for development
2. Branch for each release

This probably worked well for the other projects because they released infrequently. But my project could see multiple releases in a week, so this approach quickly lead to the server having many branches that you would not need to restore.

On the other hand, having branches for each release allowed me to quickly see the version of the code base in-use in release by a user. Not all users ran the same version, so being able to see/hotfix old versions was essential. If we had used tags for releases, it would have been far more difficult to switch between them and work on hotfix releases.

At this job, development and testing went on concurrently, so working off of master made sense there. It might not work well for places utilizing a development -> test cycle because the version that testers get could have bugs or workflow changes introduced by in-development features.