Git Branching Strategies

As a developer I have felt the pain of long, complex, merges of code. Juggling which branch to apply a hotfix, which release is in production and how we patch it. Do we roll back the code, apply the fix, then roll forward? Make a branch, fix it, then release that? And while we could do those things in the past, git can take some of the headache out of those scenarios with the right branching strategy. Having a good branching strategy also enables Continuous Integration (CI) and Continuous Delivery (CD). That being said, in general, there is no silver bullet or “Right Way”. As with software development and architecture, it depends and varies based on your team and your products. Reading about a popular strategy and adopting the most popular or first result can be painful if its not the right fit for your team. Nebbia’s expertise in application lifecyce management (ALM) and DevOps can help you find the right strategy for you, minimize the headaches, and enable CI/CD to deliver faster.

Git Branching

Branching and merging is an essential part of the daily routine of a developer using Git. While this was something you might fear in the past, with the right strategy, you can get rid of a lot of the headaches. Branches provide teams a way to collaborate on a feature or experiment on something new without impacting everyone.

Strategies

There are a few popular git branching strategies out there right now.

  • Git Flow
  • Trunk Based Development (TBD)
  • Github Flow

Each has its own pros and cons. Some are better based on team size, team experience level, product (desktop, mobile, web), or even organizational structure. There is an idea in software that has been around since the 1960s, Conway’s Law.

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway

The reason I bring this up is that the organization can influence your branching strategy where you might end up with long term environment (dev, qa, prod) or team branches. There are a few competing ideas between the branching strategies. Some strategies push for long term development branches to isolate code from production, others try to get code into the production branch as fast as possible to minimize merging. Microsoft does have some guidance on this. But let’s look at the highlights of some of these strategies.

Git Flow (Feature Based Development)

Git Flow This is one of the first major branching strategies that gained popularity. Git Flow describes multiple branches for development, releases and the orchestration between them. There are even scripts and extensions provided to help use/maintain Git Flow.

Pros:

  • Git Flow is used by a lot of distributed, open-source teams that have varying skill levels. The project maintainers can review and approve every line of code going into releases.
  • Git Flow can work well for a traditional release model, where releases are done in terms of months and weeks.
  • Git Flow also works well when dealing with an established product or multiple versions in production.

Cons:

  • Git Flow can slow things down when having to look at large pull requests if you are trying to iterate quickly.
  • Releases are hard to do more than once a week.
  • Larger features can spend days merging and resolving conflicts (merge hell) and force multiple testing cycles.
  • The Project history is full of merge commits and makes it hard to see the actual work.
  • Can be problematic in Continuous Integration or Continuous Delivery scenarios.

Trunk Based Development

Trunk Based Development I once heard it explained as, “Instead of keeping code isolated from other developers you work with, keep your features isolated from your end-users until you’re ready to release them.” Trunk Based Development lets you release more quickly, and encourages feature flag use and automated testing. Branches exist, but they are short lived and small. This minimizes merge conflicts and means smaller code reviews.

Pros:

  • Allows you to iterate quickly and still maintain quality.
  • Works well with in Continuous Integration or Continuous Delivery scenarios.
  • Can release more often, including multiple times per day.
  • Much tighter feedback loop for developers, business, and end-users.

Cons:

  • Works best with more experienced developers.
  • Half finished features not properly implemented with feature flags can cause issues.
  • Can cause some issues initially if there isn’t good test coverage or confidence in system stability.

Github Flow

Github Flow is very similar to Trunk Based Development with a few major differences. It is a lightweight, branch-based workflow working off the master branch. After the work is ready, a pull request is generated and discussion with team, the branch is deployed to production. Then the code is merged to master. There is a discussion of some of the differences in this Microsoft Build talk.

Pros:

  • Works well with in Continuous Integration or Continuous Delivery scenarios.
  • Can release often.

Cons:

  • Releasing from branches and not master.
  • Testing in production.
  • Can run into scaling issues as the team increases.

The Future

Again, one size does not fit all, and while a technique or strategy might work well for one organization, it might not work the best for you. There are other strategies and techniques out there,  Release Flow, Gitlab Flow, and others. Having Nebbia’s team work with your business and your developers we can help setup this CI/CD engine that will drive your code into production faster. We can help setup and train your team to use the tools and strategies available to increase productivity, quality, and confidence in your products.