Start your free trial
Book a Demo
Sign in

Git Branching Strategies for Your Team

How to choose the best?

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Run-through

By Gitential Team

In having recently covered How to Reduce the Size of Your Git Repository and When to Refactor Your Code, it’s logical to talk about which Git Branching Strategy you should use and when. GitFlow stands as one of the first strategies to be defined and, as such, it became a sort of an industry standard. A lot can change in ten years, but – that doesn’t mean changes are necessarily better or worse. It could be they’re just different. Either way, having more than one version control branching strategy to choose from is a good thing.

What is a Git Branching Strategy?

When working with Git, a Git branching strategy (or version control branching strategy) is the model used so that your codebase evolves in a logical, consistent, and (a mostly) “easy to understand” way. The model provides the rules for how, when, and why branches are created and named. There are different branching strategies that allow for work on like-concepts to be organized and developed in parallel.

How Does Branching Strategy Relate to DevOps?

DevOps focuses on efficiency – making things easier and faster without compromising quality. Where branching strategy is concerned, DevOps wants to know how pull and merge requests are handled, the amount of overhead involved in managing the branches. The ease of reading the project’s history could also weigh in. Mike Kaufman, a Microsoft Regional Director, MVP and VP of Consulting Services for CGI discusses branching strategies for DevOps in detail. He summarizes,

“It’s very important to find a branching strategy that fits the way the team works. If branching is not done right, it introduces big burdens and slows the team down. It also can impact the quality of your product… The best guidance is to start small and add complexity only if you need it.”

What is the Best Branching Strategy in Git?

There are many version control strategies, as Scott Shipp points out in War of the Git Flows. Now, I’ve got no problem donning a flak vest and kevlar helmet and getting down for a low crawl, but… war? That’s a tad bit extreme. Messin’ with my CCCCD Ice Cream – that’d be war! But this… this is merely like a TV episode of Survivor, but with no cash prize.

The Top Five Main Git Branching Strategies

StrategyOverview
GitFlowCreated by Vincent Driessen, GitFlow works with two main branches – master and develop – over the lifetime of the project. It also uses three supporting branches: feature-*, hotfix-*, and release-*. It’s the most complex model.
GitHub FlowA simpler strategy promoted by Scott Chacon of GitHub mandates keeping a continuously deployable main branch. A feature branch is created to work on any feature or bug fix. Each feature branch must be finished and fully tested before being merged with the main branch.
Trunk-Based DevelopmentVery similar to GitHub Flow except that Trunk-Based Development suggests deployment after production code is merged to the main branch to minimize chances for regression.
GitLab FlowCreated by GitLab, this strategy is like an extension of GitHub Flow with master and feature branches. However, it adds environment and release branches to better support SaaS and mobile projects.
OneFlowFormulated by Adam Ruka, OneFlow proposes to be a simplification of GitFlow with the use of rebase options some consider controversial.

Already, we can extinguish the torch of one of our brave contestants. Trunk-Based Development didn’t get with the Flow. It’s very, very similar to GitHub Flow. The difference between GitHub Flow and Trunk-Based Development can be seen comparing the two images below:

For a more visual demonstration of workflows, this video showcases GitFlow and GitHub Flow.

Comparing Version Control Strategies

Let’s move on to a comparison of the basic strengths and weaknesses of the remaining 4 Git branching strategy options. Each is designed for different scenarios. What’s best for a startup isn’t always going to work well for a large enterprise.

GitFlow GitHub Flow GitLab Flow OneFlow
Types of Projects Enterprise Startups All Enterprise
Branch Overhead Heavy Light Variable Light
Work Process Complexity Complex Simple Simple Medium
Merge Difficulty Hard Easy Easy Easy
Delivery Support Releases Continuous Both Releases
History Convoluted Clean Clean Variable
Feedback Slow Fast Fast Fast

There’s a lot of red flags for GitFlow. Let’s take a closer look at the GitFlow process:

It’s not so complex that you can’t understand the process, but it’s not easy on the eye, either.

GitFlow, though ubiquitous, has some limitations and issues that constrain its effectiveness. It’s perhaps the first clearly defined version control strategy to have been created. Functionally, it doesn’t work well for Continuous Delivery/Deploy or Multi-Environment projects. It works well for open-source and established/enterprise software projects so you can keep close control over any changes. It’s a useful strategy for large teams having many junior developers with close oversight by senior developers.

However, this can also lead to process bottlenecks and slower feedback. So, a moment of silence for GitFlow and its ten years of fame. GitFlow… your torch is extinguished.

How to Choose the Best Git Branching Strategy for Your Team?

Down to three – GitHub, GitLab, and OneFlow. The best version control branching strategy depends on the type of project and the size, structure, experience of your team, as noted by Mike Kaufmann.

However, when first star
ting out, it’s best to stay simple and keep it simple until the project reaches a point where additional complexity is needed. For this reason, the GitHub Flow (or Trunk-Based Development) is the best strategy for the early stages of most projects. It’s ideal for solo developers and small teams working on software projects requiring only a single version of a release to be maintained. In such cases, they may be able to stay with the GitHub Flow for the life of their project.

Projects requiring Continuous Releases or supporting more than one environment should eventually transition to the GitLab Flow. Continuous Releases apply to SaaS type projects. Multiple environments often come into play with mobile apps – which must be approved by an app store before being made publicly available. In such cases, you don’t have control over the exact timing of production releases.

OneFlow has the same limitations as Git Flow except it maintains a single long-lived branch and makes for a project history that is far cleaner and easier to read. Some developers like its use of squashing and rebasing, and others don’t. OneFlow provides more flexibility for handling team decisions inferring extra care when overseeing many junior developers. That OneFlow can do everything that GitFlow does, despite the controversies over its many options, makes it worthy of consideration.

And the Winner is - We Want You to Decide!

Not to cop out, we’re committed to making sure every vote counts. What do you think is the best Git Branching Strategy? Take our quick 1-question survey. It’ll only take you about 10 seconds. However, if you’d like to submit a detailed explanation of your reasons why you think a specific Git Branching Strategy is the best – we’d love to hear it and we’ll be happy to share it, too! And just so you know that we’re not copping out – our writer believes the GitLab Flow strategy is the best for being the most versatile of the three survivors. That’s 1 vote.

About Gitential

Our team at Gitential constantly watches trends across the software development industry. We also get down into the code with you to find ways to make it easier for you to make your team more efficient. Please take a moment to check out our free software development analytics demo – or sign up for a free trial, no credit card is needed.

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Gitential.com Inc.

  • 874 Walker Rd Suite C., Dover, 19904, DE, USA
  • info@gitential.com
  • (650) 680 7697

Resources

Legal

Gitential.com Inc.

  • 874 Walker Rd Suite C., Dover, 19904, DE, USA
  • info@gitential.com
  • (650) 680 7697

Resources

Legal

Copyright © 2021 Gitential.com, Inc. All rights reserved
Twitter Facebook-f Youtube Linkedin