Your git branching strategy is the foundation of your development workflow. Get it right, and your team will feel the wind in its sails, shipping features with speed and confidence. Get it wrong, and it can drag your team down, slowing your release velocity and increasing the likelihood of issues slipping through the cracks.

Too often, companies use a home-brewed git branching strategy. They think it's working, but it's actually impeding their ability to deliver fast and with quality.

It needs to be said bluntly:

If you're not using "Trunk Flow" or "Git Flow," you're doing it wrong.

Why the git branching strategy matters

Your git branching strategy directly impacts how quickly and reliably your team delivers software. The right strategy enables your team to work in parallel, minimizing merge conflicts and reducing integration issues while ensuring that you ship features without compromising the stability of the codebase. It sets the framework for quality control in your process. It is measurable and allows you to tweak parts of it to improve continuously.

Conversely, a poorly designed or inconsistent strategy creates bottlenecks, increases the risk of bugs slipping through, and often leads to unnecessary delays. If your deployments are being held up and take forever, there's a good chance you're using a non-standard branching strategy.

A solid git branching strategy isn't just a nice-to-have; it's a critical enabler of velocity and quality for any engineering team.

The right git branching strategy

There are two leading branching strategies for git branching. "Trunk Flow" is the best practice for modern development teams. "Git Flow" is another viable option that works well for many teams, though it's slightly older and comes with more complexity. If you're not using one of these two methods, your team's velocity and quality are probably suffering.

Trunk flow: the gold standard

Trunk flow is currently the gold standard in git branching strategies. It encourages frequent merges into a central "trunk" or "main" branch, minimizing the complexity of coordinating long-running branches and promoting continuous integration.

In trunk flow, developers integrate small, frequent changes, which keeps the codebase stable and prevents the build-up of complex merge conflicts. It also encourages continuous testing and feedback, enabling faster and safer releases.

Git flow: a time-proven workhorse

Git flow, while older and slightly more complex, is another well-established branching strategy. In git flow, development happens on long-running branches, such as "develop" and "production," with feature branches spun off for specific tasks. While managing the flow between feature, development, and production branches requires more discipline, git flow can work well for many teams.

Many teams don't know they're doing it wrong

Here's the tricky part: I've worked with teams who confidently tell me they're using git flow, but they're actually doing something else entirely. This "something else" often lacks a name, and is holding them back. The worst part is that the team usually doesn't even know it.

As someone who is brought in to advise teams that struggle to ship quickly and with high quality, I can tell you that the problem often lies in their git branching strategy. Teams will point to tooling, process bottlenecks, or team dynamics, but more often than not, the root cause is their lack of a proper branching strategy.

Are you really doing git flow?

You might think you're doing git flow, but are you sure? Here are some key questions to help you assess:

• Do you have long-running branches like "dev," "staging," or "production"?
• Do your developers commit directly to the "dev" branch, or do they create a separate branch for each task?
• Do you create pull requests from feature branches into your dev branch?
• Do you push code to production from a dedicated production branch?

If you have more than one long-running branch and answered "yes" to all these questions, you probably follow git flow. However, if you answered "no" to any of these or if the questions don't make sense for your workflow, there's a good chance you're using git flow.

The home-brewed strategy trap

One of the biggest hurdles in improving team velocity I encounter is developer apprehension about changing their git branching strategy. When teams have invented their own git branching strategy, they often cling to it—even when it's clear it's not working. They might see the issues it is causing, but they'll invent reasons why switching to something like trunk flow or git flow won't work for them.

That's where I come in. It's my job to help people see that there's a better way of doing things. Whether it's switching to trunk flow or making sure they're following git flow in a way that serves them well, my role is to convince teams that a structured, proven branching strategy will help them ship faster and with better quality—and then to work with them to make that transition.

Don't let tour git strategy hold you back

If you're noticing bottlenecks in your team's ability to ship code quickly and reliably, the issue might be with how you manage code in git. Your git branching strategy is crucial in how effectively your team operates. Whether you choose trunk flow or git flow, adopting a strategy that reduces complexity, removes bottlenecks, speeds up development, and ensures higher quality releases is key.

Don't let a home-brewed solution hold your team back. Embrace a strategy that works.