What's a branching strategy and why would you ever even need one?

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.

What is a branching strategy?

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:

• How many branches you have.
• The longevity of your branches.
• When and where you make commitments, pull requests, and deployments.
• When you should create a new branch.
• What your development pipeline looks like.

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 . . .

Why do you need a branching strategy?

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.

<!-- Code for CTA component starts here-->

<div class="post_body_cta"><div class="post_body_cta-heading">
Enjoy your work
</div><div class="post_body_cta-text">
Project management software should be helpful, not a hassle.
</div><div class="common_buttons_wrap"><a href="/signup" class="button primary text-color-white w-button">Get Started - free forever</a>
<a href="https://api.app.shortcut.com/oauth/signup" class="button is-google w-button">Sign up with Google</a></div></div>

<!-- Code for CTA component ends here-->

The two major branching strategies—and how to decide which is right for you

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

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.

Start With Shortcut Today!

The pros of GitFlow

The comprehensiveness of GitFlow gives it several pros, especially for larger development teams.

• GitFlow provides very thorough and detailed version control as merges are bundled, clearly labeled, and able to be traced cleanly.
• You can scale your development more easily with GitFlow since it simplifies parallel processing and continuous development by isolating features and ensuring that you never have to freeze either your development or master branch for release preparation.
• Many teams find that the increased visibility of this GIT branching strategy gives them added flexibility since it becomes easier to jump between parts of the development pipeline (say, between a feature for a later release and the urgent priorities of the current release).
• Your master code branch remains very clean and organized, updated only with code that has been thoroughly tested and refined.

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.

The cons of GitFlow

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:

• GitFlow sacrifices simplicity for the sake of a comprehensive structure.
• It’s difficult to iterate quickly with GitFlow’s process of moving back and forth between what could almost be considered development “phases” (Development → Release → Master → Hotfix).
• Developers tend to be more resistant to changes, especially in later stages. This is thanks to bundled code and frequent merges between branches, which makes it lengthier to go back to earlier versions and make changes.

TL;DR: The rigid structure and specific development path of GitFlow conflicts with the iterative approach of the Agile methodology.

Is GitFlow the right branching strategy for you?

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.

GitHub Flow

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.

The pros of GitHub Flow

GitHub Flow centers on Agile principles, making it a fast and streamlined branching strategy.

• GitHub Flow encourages fast feedback loops, making it possible for teams to quickly identify issues and make changes.
• Continuous deployment is pretty much a must with GitHub Flow. You have no development branch where finished features sit and wait for release. Value created quickly becomes value delivered.
• There’s less risk of technical debt with this branching strategy. Within GitFlow, one shortcut or sub-optimal piece of code can quickly get buried and become a refactoring nightmare. The emphasis GitHub Flow places on shallow structure and small changes makes it easier in the long run to identify and manage technical debt.

TL;DR: GitHub Flow is the Agile branching strategy, and comes with all the benefits therein.

The cons of GitHub Flow

As with GitFlow, the cons of GitHub Flow relate closely to its pros—sometimes, too much minimalism can be a bad thing.

• GitHub Flow is not as well-organized as GitFlow. Its speed comes at the cost of comprehensiveness and may make it harder to manage the overall development process.
• This branching strategy emphasizes constant deployment. While this can work well for some software teams, others will find it limiting as they seek to make larger releases or if they want to test multiple features together before deployment.
• The master branch can become cluttered more easily since it functions as both the production and development branch. Release preparation and bug fixes both happen in this branch—and require extra attentiveness.

TL;DR: GitHub Flow limits your options when it comes to how you approach development and release.

Is GitHub Flow the right branching strategy for you?

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.

The pros and cons of the “Do-It-Yourself” approach to branching strategy

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.

The only bad branching strategy is no branching strategy

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.

Happy branching!

<!-- Code for CTA component starts here-->

<div class="post_body_cta"><div class="post_body_cta-heading">
Give us a whirl
</div><div class="post_body_cta-text">
Because you shouldn't have to project manage your project management.
</div><div class="common_buttons_wrap"><a href="/signup" class="button primary text-color-white w-button">Get Started - free forever</a>
<a href="https://api.app.shortcut.com/oauth/signup" class="button is-google w-button">Sign up with Google</a></div></div>

<!-- Code for CTA component ends here-->