What We’ve Learned From Coaching DevOps Teams in Git Branching Strategies
The choices teams made when setting up their workflow, and the reasons for those choices, get forgotten and are rarely revisited.
Join the DZone community and get the full member experience.Join For Free
Version control is fundamental to DevOps, so using it becomes second nature for DevOps teams. But the choices teams made when setting up their workflow, and the reasons for those choices, get forgotten and are rarely revisited.
Gearset operates in an ecosystem where many development teams are still adopting DevOps. As a result, we spend a fair amount of time helping teams move from manual deployments and slow release cadences to a mature DevOps process. Even though their priorities and challenges vary, teams in small startups and large enterprises alike are all looking for the same thing: the agility that comes from DevOps.
Adopting version control is the first step on the journey for these teams, and we guide them on the way. Usually, the most involved part of this process is a discussion about Git branching strategies. We think the advice we give holds true for any teams looking to revise or implement their own Git branching strategy.
Take One Step at a Time
Teams that take things one step at a time towards DevOps maturity tend to see the most success. Making incremental improvements allows these teams to see the benefits of each change, getting to grips with new tools and processes before moving on to the next thing. Teams that bite off more than they can chew by trying to implement everything at once often struggle with such a radical change.
Solving today’s problems is the best way to prepare for tomorrow. While it’s a good idea to consider the challenges you’ll meet in the future, skipping ahead isn’t the best way to transition successfully to a DevOps-driven workflow. Adopting or revising a Git branching strategy is one step on the journey to DevOps maturity; it’s best undertaken on its own, not as part of a wholesale revision of your existing workflow.
Question Your Current Process
If skipping ahead in making DevOps improvements is one danger, inertia is equally problematic. Ingrained behaviors in your team shouldn’t dictate the processes you use, including your Git branching strategy.
The whole question of Git branching strategies arises because there’s a choice to make between valid options. Teams usually make their choice based on team size, team structure, the release cadence they’re aiming for, and their current workflow. All of these are important considerations. But we recommend that teams don't just settle for a revised version of their current process because it might not be the best option.
Implementing a new strategy represents an opportunity to reshape your workflow, and teams should take this opportunity to assess whether their current process is the right one. Some teams can simplify their workflow and increase release velocity. Others may need a Git branching strategy that supports an increasingly complex workflow with a range of environments.
We ask teams to identify their goals, their capabilities, and the sticking points in their current process. It can be difficult for teams to identify the sticking points in their own process — many find an outside perspective invaluable when it comes to identifying what's broken and what other options are possible. Once all of this is clear, the team is ready to pick their Git branching strategy.
Adopt the Simplest Possible Git Branching Strategy
Teams come in all shapes and sizes, and as a result, some find it easier than others to adopt a new Git branching strategy. Large enterprises sometimes have complex workflows that necessitate a complex Git branching strategy to match. That said, in our experience, teams often believe their particular requirements call for a uniquely complex process, when in fact a simpler option would be much more suitable and much more accessible to newer and less technical team members.
The bottom line is that the simplest possible Git branching strategy within the constraints of a team’s workflow is usually the right choice. We recommend that teams adopt a strategy based on the feature-branch model if possible, with new features developed in short-lived branches created from and merged back into the main branch.
For teams wanting to maintain a weekly or bi-weekly release cycle, we usually look at adopting the Gitflow model. In this model, teams merge new features into a permanent ‘develop’ branch. Then individual release branches are created from the ‘develop’ branch and merged into the main branch. Releases continue to be periodic, but any tricky merge conflicts are dealt with as features are merged into the develop branch — not during the release.
Don’t Impose a New Strategy Without Buy-in From the Team
While a new Git branching strategy can be the right choice, it’s a mistake for team leaders to impose a new strategy quickly without first getting buy-in from the whole team. If team members are confused about a new process and have different expectations of how branches ought to be used, confusion and frustration will soon follow.
The benefits of a change in the process need to be visible quickly for teams to get on board. Whether it’s adopting version control for the first time or adjusting the setup, change for the sake of change won’t appeal to anyone.
Getting the Right Balance
While teams are often looking for agility and an accelerated release cadence, velocity shouldn’t come at any cost. Teams must balance velocity against the requirements of their organization and their own capabilities, building a robust workflow that delivers value both efficiently and effectively.
Opinions expressed by DZone contributors are their own.