In this course, we've seen how the differences between centralized version control systems like TFVC in distributed Git-based systems impacts multiple and remote teams, and how these different architectures deal with access permissions. I think it's fair to say that Git and its derivatives are the preeminent systems at this time, and the main reason for this is branching.

Branching is technically easy and often referred to as cheap in comparison with centralized systems equivalence. While branching may be quick and easy, as with everything in life, there are no free lunches and all branches must end up being merged back into the main or master trunk in the end. This merge date must be repaid through the pull request mechanism. This is where we see how our different branching strategies evolved to lighten this burden.

Obviously, not all software projects organizations are the same and they have different needs, but what I find interesting is how branching models proliferated, became more complex, and convoluted, but we're always hamstrung by the same basic issue; merging. In this new automated DevOps world, this very important, but potentially manually intensive task is a real fly in the ointment. I like how the release flow strategy goes back to basics, which is trunk-based development off the master branch, but with a twist of using feature flags to isolate incomplete work. This method addresses one of the key pain points by keeping branches as short as possible and related to just one feature or function. Of course, no branching strategy is a silver bullet and the release flow only fulfills its promise with a rigorous testing on branches before the pull request.

There are always going to be situations where you need to revert changes and this is sometimes referred to in complex situations like trying to get the sugar out of your coffee. Smaller branches merged more often can definitely minimize the associated grief in this situation. The bottom line is that all strategies are conventions using the same tools and is up to you to settle on a strategy that best works for you. Having said that, repository systems do offer mechanisms to enforce best practices or the strategy you have decided to adopt.

In Azure DevOps, branch policies can enforce proper behavior within pull requests by requiring a minimum number of approvers, for example. Branch policies also allow you to enforce particular merging strategies. Finally, we took a look at integrating third-party repositories with Azure DevOps pipelines and how to integrate Azure DevOps repos with a Jenkin build pipeline. It turns out we're spoiled for choice with version control systems and it's just a case of finding which one is most easily adapted to your situation.