Silly Arguments – Git Branch Strategy

| April 24, 2018 | in

Git is amazing.

If you’re not familiar with Git, it is a source control system that actually works. There are many improvements that Git brought to how we manage projects, but a big one is that Git really supports branches. Git will do something no other source control supported (that I had worked with): branching code and merging it back in. It actually worked!

Now with this support comes more questions, such as “how should we branch”? Again, this tends to become an area of huffiness within development circles. Some people tend to want only one feature branch per feature, then merging that feature branch back into master. Others want more complex flows, such as a branch per environment.

Some developers believe there are one-size-fits-all Git branching strategies; always “feature branch into master” or always GitFlow. For what it’s worth, I think both are valid options. Let’s look at both.

Feature Branch Example

We create a branch for developing a discount engine. We do many commits in that branch, then eventually merge it back into the Master branch.

GitFlow Example

We have a Feature branch created from Develop. We also have a hotfix created from Master around the same time. The hotfix branch is merged into Master as part of a hotfix release. The Feature branch is merged into the Develop branch, where testing is done. After it passes QA, it will be merged into Master as part of another release.

For extremely simple projects that have frequent releases, I think only using feature branches that merge back into master makes a lot of sense. The more frequent the releases, the less likely you need other branches per environment.

I think GitFlow makes a lot of sense (or a derivative of it) if you have multiple environments and releases often occur slower than hot fixes. If you hot fix daily but release new features monthly, you probably need to use something like GitFlow.

In the end I think picking the right Git branching strategy is a project by project decision.