Branches make a lot of sense if you're a developer (or a tree, depending on the branch you're talking about) — they’re a nifty little place to keep your work-in-progress, make sense of new features, and work on issues. But if you’re not careful, you can get too much of a good thing.
We’re talking opaque version control, inconsistent practices for developers, ill-defined workflows—without a solid branching strategy, your development pipeline will become the Wild West. And only a few pieces of good software were ever built in the Wild West. .
So let’s get acquainted with the new sheriff in town: branching strategy. Come along with us to see just how many different tree / branch metaphors we can make.
Code branches can be a great way to organize your development pipeline—but like tree branches, they’re only viable when they’re part of a whole. Otherwise, they’re just sticks cluttering your yard.
A branching strategy ensures your codebase stays pruned and healthy by governing how and when branches are created and used. If it helps, you can also think of this as your branching structure, as the strategy you choose will determine how work flows between code branches. It will also affect:
This might sound like busywork—after all, as long as quality code gets shipped on time, does it matter what kind of branches you use to get there?
What you’re really asking is . . .
The short answer: Too many branches will leave you with a tangled mess.
The longer answer: Branching can offer many benefits in terms of version control, efficient processing, and overall pipeline organization. To actually gain those benefits, however, you need a cohesive structure that everyone understands and follows.
Before you flip a coin to decide what approach to take, understand that the way you structure your branches isn’t a tactical decision. It’s very much a strategic decision—one that affects not only your coding workflows, but also core development issues like feature prioritization, bug fixes, and release management.
Agile teams, especially, need to align their branching strategy with their guiding principles. Branching should support a sustainable delivery pace—not create short-term gains in speed that create complications or technical debt further down the road.
But don’t worry: For all its importance, branching strategy isn’t that complicated. In fact, there are only two major strategies when it comes to a GIT branching strategy: GitHub Flow and GitFlow.
While some teams choose to create more bespoke branching strategies, two branching strategies are widely recognized as industry standards. Their names may be similar, but the strategies themselves take nearly opposite approaches to branching.
There’s no one right answer when it comes to these GIT branching strategies that’s right for you, but we’ll break down the pros and cons of these two major branching strategies and give you our take on whether one will perform better for you or not.
GitFlow offers teams a deep, detailed structure with a few clearly defined branches: master, development, features, release, and hotfixes. Each of these GIT branches has a specific purpose and is used to isolate a part of the development pipeline for parallel processing and enhanced quality assurance.
The master branch is your production-ready code; you’ll ultimately merge all code branches into master in order to deploy it.
The development branch is where you’ll merge all your features and changes before ultimately merging the development branch with the master. Think of it as almost a “pre-production” master branch. Feature and release branches stem from this branch.
Feature branches are where you’ll work to develop new features—one branch per feature. These branches make it easy to track versioning on a more granular basis and to have various teams or developers working on multiple features at the same time.
The release branch is used so you can avoid freezing the development branch while you prepare for a release—thus allowing teams not working on a specific release to continue their work. Create this branch only when you’re working specifically on a release. Only release tasks, such as QA, bug fixes, and documentation, belong in this branch. When the release is ready, you’ll merge with the master branch and deploy from there.
Hotfix branches are short-lived branches used exclusively to patch production code. The idea is that by isolating problematic code from the master branch, you’ll have more flexibility to quickly fix bugs and test your fixes without affecting the production code directly (until you’re ready to merge).
This is a lot of branches, but many teams appreciate the clear structure and the workflow guidance that GitFlow offers. However, like any branching strategy, it has both strengths and weaknesses.
The comprehensiveness of GitFlow gives it several pros, especially for larger development teams.
TL;DR: Teams who embrace the somewhat rigid structure of GitFlow can leverage branches to improve pipeline visibility, increase overall flexibility, and organize code more cleanly.
Unfortunately, the pros of GitFlow lead to a few major cons as well, which all fall under this one complaint: GitFlow is not very Agile-friendly. This occurs in a few key ways:
TL;DR: The rigid structure and specific development path of GitFlow conflicts with the iterative approach of the Agile methodology.
GitFlow is ideal for larger teams who have a lot of irons in the fire. If you rely on major releases and updates, if your product requires frequent maintenance patches, or if you’re developing a lot of features at once, GitFlow can be a great way to keep your team organized and scalable.
In contrast, GitHub Flow uses a very minimal, iterative branching structure. The emphasis here is keeping the master code branch consistently deployable. Thus, features, releases, and bug fixes all happen within the main development pipeline, instead of in their own isolated pipelines.
GitHub Flow only has one permanent master branch—there’s no development branch here. Instead, feature branches stem directly from the master. Development, commits, pull requests, and testing all happen in this feature branch. When it’s ready for release, it’s merged directly to the master branch and deployed from there. The feature branch is then deleted.
GitHub Flow centers on Agile principles, making it a fast and streamlined branching strategy.
TL;DR: GitHub Flow is the Agile branching strategy, and comes with all the benefits therein.
As with GitFlow, the cons of GitHub Flow relate closely to its pros—sometimes, too much minimalism can be a bad thing.
TL;DR: GitHub Flow limits your options when it comes to how you approach development and release.
If you’re an Agile team, GitHub Flow will likely suit your needs better. GitHub Flow gives you a way to align your team around a clearly-defined process for new features and fixing bugs, while also keeping your pipeline as streamlined and delivery-focused as possible. Just make sure your team adheres to this branching strategy and doesn’t use the minimalism as an excuse to create their own individual branches.
Some say a “branching strategy” is simply what specific types of branching you use. (For example, you could choose to use feature branches, but not release branches.) This is a valid approach, as long as your strategy remains cohesive and clearly communicated.
The major upside to a DIY branching strategy: You can go nuts! It’s easy to build a branch structure that makes sense for your unique situation and vision.
The major downside to a DIY branching strategy: You can go nuts. If you’re not careful, a DIY approach will too easily lead you right back to that lawless Wild West you wanted to avoid in the first place.
We’d recommend starting with one of the two main branching strategies and adjusting as needed instead of going straight to à la carte.
Don’t worry about creating the perfect branching structure on the first try. It’s much better to start with something and adapt the strategy to your needs over time rather than weighing pros and cons while your code repository gets messier and messier.
A word of advice, though: Don’t make this decision in a vacuum. Talk to your team; take some time to understand how they’re already working. Get their input on what branching approaches have worked well for them—on their current teams or in past positions.
Ultimately, you want a branching strategy that will make your team more productive, so it’s worth gathering input across various teams and positions to get a sense of how you can meet that goal. When you decide on a branching strategy, however, make sure it’s used consistently, understood comprehensively, and communicated clearly.
Nothing to see here...