Fowler's Branching Patterns

Martin Fowler is prolific writer about software development. One of his more well-known books is probably Refactoring. He also has a blog with lots of good content. After reading the Continuous Delivery book and working on my Using Git Effectively course, I have been thinking a lot about branching strategies. Luckily Martin wrote a great article that lays it all out. You should really read the entire article. I’ll try to hit some of the highlights here.

One of my big revelations was his definition of the term branch. He hits on the idea that with a Distributed Version Control System like Git when you clone a repository and start making local commits on master, you’ve essentially created your own branch. Yes it has the same name as the master branch on your remote, but it’s a separate line of development. You are working in your own sandbox and at some point you will have to merge changes to stay up to date with the remote repository.

Martin drives home the advantages of Continuous Integration. He clearly explains the reasoning. Rather than one large merge when a feature branch is “finished”, it is better to have many smaller merges. Not only does that allow us to continuously integrate our code, but it makes the merges themselves much less painful.

He also talks about the GitFlow paradigm. He acknowledges that there is some merit to having long-lived branches and using pull or merge requests to review code before merging it in. However most of those advantages only apply to open-source development where timelines aren’t as tight and developers aren’t trusted. In a more traditional software development paradigm, a continuous integration approach is more relevant.

All of my recent research has really made me rethink my use of GitFlow. I will probably continue to use it on any open-source projects. However for most of my other project-based work I will be moving away from Gitflow towards a more of a Continuous Integration approach. To quote the Agile Manifesto: We are uncovering better ways of developing software.

Help

If you would like help discovering better ways to write software. We’d love to talk to you and share what have learned and see how we can help you.