When your project becomes bigger and also your team grows, it is time to choose a good strategy that fits your project needs, if you haven’t done that yet, but if you have chosen one, and you think it is slowing things down, maybe you should migrate to a whole new strategy or implement different practices. That’s why I’m going to share with you some key points to have in mind while developing a git branch strategy.

Table of Contents

What Do We Need To Have Into Account?

Before we start talking about branch strategies, there are a bunch of things we should have into account and analyze to make a better decision. Things like: do I actually know how to use Git and how it works? How big is my team? Is the project in a production-ready state? Is it at least being versioned?. We are going through some of these questions and analyzing some concept.

What Is Git For And Why It Was Created At First Place

As stated in Git’s official page: Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency and they afford this by not forcing a particular way to use it but giving enough tools to let the user define how he/she prefers to work.

It is also stated in the Pro Git book Git began with a bit of creative destruction and fiery controversy and it was controversial indeed. But the most important thing about the problem that forced Linus Torvalds to start developing this tool is what he and his team learned while working on Linux and the goals they defined to be reached:

  • Speed
  • Simple design
  • Strong support for non-linear development (thousands of parallel branches)
  • Fully distributed
  • Able to handle large projects like the Linux kernel efficiently (speed and data size)

These characteristics, which have been proved to be well-implemented on Git, are the reason we have tons of strategies, and we can use any of them that better fit our project’s needs.

There Are No Silver Bullets

It is very important that you understand that there are no silver bullets for project’s branch strategies, the decision depends on a lot of factors, so instead of trying to reach that Holy Grail, just implement the one you think better fits your needs and then improve it based on continuous feedback from your whole team and continuous performance revisions.

The Simpler, The Better

“Simplicity -the art of maximizing the work not done- is essential” — 10th principle of 12 Principles Behind the Agile Manifesto

Simplicity is often a misunderstood concept related with ease, but curiously it’s very hard to understand what it means. For the purpose of this article we are going to define Simplicity as:

“The optimization of the resources needed to reach a goal”.

Let’s try to expand the concept by saying that if there is anything on your process that is not needed to reach your key goal, probably you should get rid of it. And I mainly mean all those fancy sub-process designed to over-control the development process, if it is slowing down your path to feature release then try to change the way you collect data, perhaps implementing more automated processes. Make the first agile principle be you most important goal: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

One of the must beautiful things I’ve realized about working on simplicity and trying to reach it, is that simple process become intuitive and this is very powerful thing, because you ease the onboarding process of new developers and their learning curve and your team is not forced to write an extensive documentation that will be a waste of time for those who actually learn better empirically.

Know Your Project Better

There are some questions you need to answer before defining the strategy to implement:

  • Is your code production-ready? Or at least an MVP?
  • Do you give support to multiple versions of your product at the same time?
  • How large is your project?
  • Is the product modularized? Are those modules maintained by different teams?
  • Is it a single-team or multi-team project?
  • How are responsibilities distributed on your teams?
  • Is it open source?
  • What reports do the stakeholders require? Can you automate the data gathering?
  • Are you using some kind of Project Management System, and how does it handle your code?

The more you know about your project, the better the decision will be.

It is also important to think about how the number of developers will grow in the nearest time, but don’t overthink about it, I like to say that if the problem you’re analyzing is not jet a problem, then solve it later when it comes to be real and focus on what you need now.

The Practices To Avoid

Of course there are some practices you need to avoid for the sake of simplicity, sometimes they are sort of inevitable, but make them the exception that proves the rule and avoid them the must you can. Some of them are:

  • Multiple developers working on the same branch, they will probably fall into conflicts solving very often, instead try implementing pair-programming
  • Don’t overthink and just try-review-improve
  • Avoid long living branches, they use to get outdated and also become hard to maintain. As a rule of thumb a branch should not exist more than one sprint if you’ve implemented SCRUM.

The Practices To Embrace

  • Keep your working branch up to date by merging your target branch regularly to avoid bugs or conflicts while you’re developing new features.
  • Commit regularly and define some commit policies. This way you wouldn’t lose your work and your log will be clean.
  • Start from a simple a base. There is no need to create a lot of branches while you are not even sure about what will be your strategy. By now master is the default branch so use it for developing if you’re just starting.
  • Main and development branches should always be on a working status. That doesn’t mean you cannot merge not-full-implemented features, just ensure your new code doesn’t brake anything.
  • Implement Unit testing and CI/CD process.

Common Strategies

There are tons of resources on internet defining multiple strategies you should check, but I’m going to share some I found interesting with you, also I encourage you to do some research and test those you like. Next three articles where the first I found six years ago when I started wondering how to use git efficiently:

Next articles will also help you on your pursuit of implementing the best strategy, some of them compare different strategies and state their pros and cons:

Comparative Analysis of Git Branch Strategies

Below is a comparative analysis of various Git branch strategies, highlighting their features, advantages, drawbacks, and potential for integration with other strategies:

Strategy Key Features Pros Cons Related Strategies
Git Flow
  • Feature branches
  • Release branches
  • Hotfix branches
  • Clear structure for different stages
  • Well-suited for scheduled releases
  • Complex for small projects
  • More branches to manage
  • Feature Branch Workflow
GitHub Flow
  • Single main branch
  • Feature branches off main
  • Direct push to main branch
  • Simplified workflow
  • Better for continuous deployment
  • Quick iterations
  • Less suitable for scheduled releases
  • Complex development/QA processes
  • Trunk-Based Development
  • Feature Branch Workflow
GitLab Flow
  • Combination of Git Flow and GitHub Flow
  • Environment branches for staging and production
  • Flexible and adaptable
  • Supports both continuous delivery and scheduled releases
  • More complex to implement
  • Requires disciplined branching and merging practices
  • Git Flow
  • GitHub Flow
Forking Workflow
  • Developers fork the repository
  • Changes are merged back via pull requests
  • Ideal for open-source projects
  • Maintains a clean main repository
  • Overhead in synchronizing the forks
  • More complex for small teams
  • Feature Branch Workflow
  • GitHub Flow
Feature Branch Workflow
  • Features developed in dedicated branches
  • Merged into main branch after completion
  • Isolates feature development
  • Reduces risk of breaking the main codebase
  • Can lead to diverged codebases
  • Requires discipline in branch management
  • Git Flow
  • GitHub Flow
Trunk-Based Development
  • Developers work on short-lived feature branches or directly in trunk
  • Emphasizes frequent merges and small, incremental changes
  • Promotes continuous integration
  • Minimizes merge conflicts
  • Fast-paced
  • Requires a robust CI/CD pipeline
  • Not ideal for rapid change averse teams
  • GitHub Flow

This table serves as a guide to help teams and developers weigh the options and make informed decisions about which Git branch strategies to adopt or combine for their projects.

The Strategy I Start Any Project From

Most of the characteristics you have to have in mind taking the final decision are related to the project itself, but it is also important to work with the one you feel comfortable with, since that is the one you know better, of course you can always adapt it to the project specific requirements.

Before I explain the strategy I use, it is important to say that most of the projects I’ve managed has been hosted on Gitlab, something that of course impacts on the model itself.

Branches

  • master is my default development branch, I don’t even bother creating a new one if I don’t need it.
  • production, as you can guess, is the branch where I manage the last production-deployed version.
  • topic branches, always targeting master and usually named as {type}/{issue-id}-{issue-description}. V.g.: — feature/1444-some-awesome-feature — bug/1449-an-ugly-error

I don’t use to use pre-release branches and I once worked with version-branches which turned out to be a waste of time for my needs then.

For hotfixing, I merge into master and then cherry-pick to production, because default target on Gitlab is the main branch and my team doesn’t have to change anything but the subject and description of the MR.

Changes Control

Every single branch should be related to an issue of any type through a merge request (MR) and we try to avoid having more than one MR per issue, although it is prohibited to have an MR related to more than one issue.

The process starts by creating the MR, then, after pushing the code to it, the CI triggers automated test and, as a project manager, I review the code. Once approved, the branch is merged into master triggering the CD to a testing and staging area.

That’s pretty much it, simple but effective, and of course, adaptable and a subject of improvements.

Conclusion

Your final decision is upon your project needs and your knowledge, which also comes to play an important role, that’s why you should start by trying any strategy you like and then making the necessary changes. The most important things are always being open to improvement and feedback.