The best Git branching strategies

The perfect Git branching strategy can help your development team get more done with fewer mistakes and minimal code-loss catastrophes. However, a bad choice of branching strategy in Git can quickly frustrate your team members, slowing down development considerably in the process.

The strategies below each have their strengths and weaknesses. Read on to learn what would work best for your team's needs.

1. GitHub Flow

This Git branching strategy takes aim at the issue of complexity inherent to other branching strategies by simplifying the way in which codebases are built over time. As opposed to structuring development and branching processes around larger version changes and releases, GitHub Flow focuses on facilitating smaller and much more frequent deployments to production.

GitHub Flow itself is simple enough to be condensed into three parts:

• Treating the main branch as deployable at all times and deploying changes merged into it immediately
• Creating each new branch off of the master branch with a name that describes its purpose. This would make naming a branch for a login feature "login-feature" an appropriate tactic, and you would push work committed locally to this branch on a regular basis.
• Opening a pull request when your feature in development is finished and merging it into the master branch once it has been reviewed.

➕ Pros

GitHub Flow offers teams the kind of development speed that can turn into a real game changer at market. New, experimental features can be laced up and deployed in very little time, leading to incredible development agility that can truly give your organization an edge over the competition.

GitHub Flow is perfect for teams looking to streamline the inclusion of minor features in production environments in real-time. Bug fixes and security issues are also simpler to handle as changes to code are small enough to address in full along the way.

➖ Cons

This approach to Git branching does not necessarily tie in well to explicitly versioned software development practices. Frequent code changes can create headaches in such instances and are less preferable when compared to larger, planned pull requests.

2. Git Flow

This Git branching strategy approaches the issue of protecting vital code by structuring all branching activity around the concept of preparing and deploying "releases." This is managed with a couple of permanent branches and a dynamic range of supporting branches. The latter of these two groups provides much-needed flexibility while the former retains the rigid structure certain development environments depend on for strict version control.

Git Flow can be summarized by the following points:

• There should be a main branch for deployment-ready code and a develop branch for new features.
• Feature branches are created by branching off of the develop branch and are either merged back into the develop branch upon completion or discarded as necessary.
• These branches should generally not exist on the origin server at all as they are meant to facilitate local development only. When these branches are actually merged with the develop branch, the --no-ff option should be used to prevent fast forwards that would otherwise erase evidence of the feature branch ever having existed at all.
• Release branches should be used to polish up new versions of the codebase before they are merged with both the develop branch and the master branch.
• Hotfix branches can be branched off of the main branch, but must be merged into both the develop and master branches upon completion.

➕ Pros

The Git Flow branching strategy allows developers to work on explicitly versioned code and manage multiple versions simultaneously with relative ease.

➖ Cons

One of the most prominent complaints people have about the Git Flow branching strategy is that it can often be a bit too complicated for development teams to use. Although team members can generally learn how to use it with time, the fact remains that added complexity that is entirely unnecessary does nothing but bog down development efforts. This creates a powerful spiral of confusion and apathy among team members if left unchecked, leading to mistakes being made over and over again.

Git Flow's originator actually states in fairly unambiguous terms that it does not work that well for software that should be delivered continuously. This generally applies to web apps and similar varieties of software in which releases are never rolled back or only a single version of the software is actually supported in production.

3. GitLab Flow

GitLab Flow focuses on features to provide developers with a branching strategy that pairs the best parts of the Git Flow with a solid issue-tracking system. This is accomplished through the use of a production branch that reflects your project's deployed code. However, there are also environment branches and release branches to consider with this branching strategy.

The GitLab Flow branching strategy can be summarized as follows:

• Your production branch should reflect deployed code.
• Environment branches are used to handle staging deployments, etc.
• Release branches should be used for deployment to the outside world.
• Code changes should stem from issues tracked in GitLab.

➕ Pros

A production branch helps track releases with less complexity than the Git Flow.

➖ Cons

This branching strategy is largely designed for GitLab users. Teams that do not use GitLab might not have as strong of a need for this arrangement.

Choosing a Git branching strategy 🥰

Your choice of branching strategy in Git is important and should reflect both the needs of your organization as well as your development team. Check out our article on GitOps for more Git branching strategy information. Mergify can make many common GitHub activities much easier to manage by lending your developers the transformative power of automation. Learn more about what Mergify can do today.