Simplified Git Workflow

I’m always looking for ways to simplify and optimize pretty much everything that I do. Naturally, my obsession for streamlining carried over when I started using Git to manage my code. Over the past year or so I’ve been experimenting with different workflows or branching models for Git. In this time I’ve worked on projects that used a single “long running” branch, to projects with 10 or more branches. This post outlines the workflow that I’ve found to work best with most projects.

How Many Branches Do You Need?

Regardless of how small your project is, one branch is just not enough. On the other hand, trying to manage too many branches can be both tedious and confusing, especially when several people are working on the same project. So, what’s the magic number of branches? I’ve found that the majority of projects can be successfully maintained with just three branches: Master, Development, and Hotfixes. The following image shows a (very simplified) example:

Simplified Git Workflow

Master Branch

The Master branch holds a pristine, “production ready” copy of the code. The Master branch is the only branch that gets pushed to the production server(s), so any code changes should be tested in staging, pass any unit tests, QA testing, etc. before being merged back into this branch. You should never make edits directly in the Master branch.

Development Branch

The Development branch is your long running branch. Use it to implement new features or to make any changes that will take more than a few hours (or a few days, depending on the size of your project and how many people are working on it) to complete. Code from the Development branch can be pushed to a testing or staging server, but — once it has been tested and verified to work — it must be merged back into the Master branch before being pushed to production servers.

Hotfixes Branch

The Hotfixes branch is a temporary branch. It’s always created from the current Master branch, and is mainly used for tasks like quick bug fixes and patching critical security flaws. The Hotfixes branch can also be used to add newly requested (urgent) features, or to make any changes that need to be done before your Development branch is ready for production. Always remember to merge Hotfixes back into Master and Development once you’re finished.

A Final Word

I’ve successfully used this workflow on small personal projects, as well as large projects that have several contributors. I think the reason this model works so well is because it’s simple to implement and follow. You could use a more complex workflow, but I’ve found that anything more than three or four branches tends to be overkill for the vast majority of projects. Experiment with different branching models until you find one that works for you and your team.

Leave a Reply

Your email address will not be published. Required fields are marked *