Git has become the ubiquitous source code management since its introduction in 2005. Along the way, a number of branching strategies (“workflows”) have evolved. As with anything in software architecture, there is no one right way to do anything; it all depends on context. In this post I’ll describe three common workflows to help you choose the simplest Git workflow for your team.
Basic Workflow
In this workflow there is only one branch – master. Everyone commits and pushes their changes to master. All team members can readily see all the changes to the code base. Your build server is easier to configure because it only needs to respond to changes on master. As a result, the team gets faster feedback because everyone is working on the same branch. This workflow is suitable for when the pace of development is slow, and the team can complete all the features planned for the coming release.
Where the Basic Workflow becomes a problem is when the development pace is faster than the release cadence. In other words, when the team decides to take a release through QA testing and production deployment while simultaneously working on features for the next release. You can overcome this by using feature flags to hide new features from the current release. But the code needs to be clean and modular in order for feature flags to be useful. Spaghetti code and bad designs won’t work with feature flags.
Feature Branch Workflow
Similar to the Basic Workflow in that there is only one permanent branch – master. But each new feature has its own temporary branch, known as a feature branch. A developer creates a feature branch from the head of master, and makes all their changes on that feature branch. When they are done, they merge it back in to master, and delete the feature branch. Many teams have the developer issue a pull request (PR) before merging so the lead developer or other team members can review the changes. Once approved or up-voted, someone merges the feature branch back into master.
It’s important that each developer frequently merge changes from develop into their feature branch. This should be done at least once a day so that they incorporate other team members’ work into theirs. It also avoids merge conflicts and breaking builds since everyone can keep their local copies up to date.
This workflow is handy for tracking the code changes for a particular feature. When the team names their feature branches after the feature name, tracking is simple. In fact, Atlassian’s Jira makes this easy. Another is the use of PRs promotes learning by having other team members review the code changes. It also helps a lead developer or architect monitor the evolving design of the software.
One drawback is not everyone sees the changes to the code base. If you are on master, you won’t see a developer’s feature branch until it is merged back in. Another drawback is if your build server (Jenkins, CircleCI, etc.) is configured to look at just one branch (master), there is a delay in feedback until the feature branch is merged into master.
Gitflow Workflow
In the Gitflow workflow there are two permanent branches – master and develop. The master branch reflects what is in or on its way to Production. Feature branches are taken off develop and merged back in. When the time comes to make a release, the team merges develop into master.
This workflow is great for when the pace of development exceeds the release cadence. When the team decides to make a release, they merge develop into master so the latter now has all the features planned for the upcoming release. Work on the next release continues on develop, with feature branches created off it and merged back into it.
The Gitflow Workflow handles production hot fixes quite nicely too. These are critical fixes that cannot wait for the next scheduled release. Take a branch off master to work on the hot fix. When complete, merge the hotbox branch into both master and develop.
Which Workflow Do We Use?
So there you have three of the most common Git workflows. But how do you choose? My advice is to choose the simplest Git workflow for your team. Start with the Basic Workflow. If that works for your team, great! If you realize you need the capabilities of one of the other workflows, and you can live with its drawbacks, then adopt it. Conversely, if one of these workflows turns out to be overkill for your team, you can fall back to a simpler once master and develop are aligned.
