If you want to ignite a debate in a pub, casually start chatting about politics. In a [virtual] room of software engineers, gently mention branching strategies and pull requests. In both scenarios you can sit back and enjoy the vibrant chain reaction of experiences, opinions, and myths. In this brief article I will share our experience, our standardization of branching strategies, our use of pull requests and bust a few myths along the way.

Branching Strategies

There are many, such as trunk-based, GitFlow, GitHubFlow, and derivations as documented by the former Microsoft ALM/DevOps Rangers and Microsoft Docs.

We have been experimenting with GitFlow and Trunk-based branching strategies and are supporting both as part of our common engineering ecosystem and associated guardrails (aka governance). Based on a push for consistency and standardization we are recommending the trunk-based branching strategy, with release branches, as used by the Azure DevOps product team.

WHY?

• It is simple.
• It has been adopted by our engineering teams.
• It fits well with our app-type blueprint initiative.

I am NOT saying that is the best strategy but based on experimentation it fits our people, process, and products.

MYTH 1 - One branching strategy is better than another!

There is no silver bullet! Avoid the debates and invest time to experiment with a few of the common branching strategies, to determine the best fit for your PEOPLE, PROCESS, and PRODUCTS.

See trunk-based release from branch for the variant that we are using, based on learning from the Microsoft Azure DevOps team. It is a strategy that works well for the 1-2 pizza sized teams, as well as product teams with hundreds to thousands of engineers.

MYTH 1 - Trunk-based branching strategy is suited only for small and experienced teams!

The Microsoft Azure DevOps and Microsoft Office are two very large teams that demonstrate the trunk-based branching strategy scales from small and rapid experimentation and innovation teams, to large product-based teams.

The takeaway for you is that the answer to "what branching strategy is ideal for you?" is "it depends on the outcome of your experiments!"

Pull Requests

Which brings us to pull requests (PRs), which enable us to change, review, and merge code. You can add policies to your PRs to enable code quality in key branches using policies, validation builds, code-quality and security scans. I trust you all want to protect key branches such as trunk/master/main, which should always be stable and deployable.

MYTH 3 - Pull-requests slow down your continuous integration value stream!

A pull request takes as long as you and your process allow it to sit in a corner to gather dust. We encourage our engineers to track the lead and cycle times of pull requests using the Pull Request Completion Report and to collaborate with their peers to ensure that pull requests do not go stale.

Make sure you have a working agreement for pull requests, because you decide how long the average lead and cycle times are for your pull requests. In our case:

• Code-quality, security-scans, and validation build(s) take minutes at the worst.
• Code review for learning can be done in parallel without affecting the lead and cycle times, so no delays.
• Branch policy checks, such as must be linked to work items and all comments must be addressed, is instantaneous.
• If feature branches are short-lived, collaboration is healthy, and code changes constrained to agreed feature(s), the code reviews are also in the territory of minutes.

So, we are talking about minutes to add immense value and ensure that the changes we commit to trunk/master/main branch are quality and will not break. If your average pull request lead time is in the hours to days, you need to map your pull request value stream and find the WASTE.

MYTH 4 - Pull-requests are manual gates

In theory a pull request (in Azure DevOps) could be all automated, based on policies, validation builds, and other validations. It is as manual and/or automated as YOU decide to configure your policies and guardrails.

If you wonder whether it is a sin to use pull requests with trunk-based branching strategies, read continuous code review and watch the trunk-based development video.

MYTH 5 - Trunk-based branching strategy and use of pull requests is a NO-NO!

"In theory" the trunk-based strategy is based on short-lived feature branches and merging changes directly with the trunk/master/main branch. Using a pull request as a pre-merge validation does not change the strategy, it merely injects a final countdown checkpoint before you commit your code changes to the "always deployable" trunk/master|main branch. It is an opportunity to move your scale of trust, not a matter of changing the branching strategy.

For branching strategies and the use of pull requests there is no silver bullet. Once you realize that consistency and standardization trumps personal preference and variations, you can pick the branching strategy and the use of pull-requests (or not) that empowers your engineers and organization.