Summary
In this module, you learned about branching in Git. Branching is used to separate your development code from the test and/or production code. If you need to fix a bug in the production code, you can always do this without worrying that you're going to release unfinished code, because that is in another branch. Once you're finished with the development of your feature, you can merge your changes back into the development and/or main branch.
With Azure DevOps, you can set branch policies that prohibit users to commit or merge directly on that branch. Changes must be merged using a pull request. In the branch policy, you can specify the requirements on the pull requests. You can set the minimum number of reviewers, build policy requirements, and so on.
We also looked at different branching strategies that you can apply, depending on the type of project you're working on. The feature strategy is useful on per-tenant extensions, while for an add-on extension, the release strategy makes sense.
A typical development flow can be defined as:
Create a remote feature branch based on the main/develop branch.
Pull the feature branch locally with Visual Studio Code.
Make your changes and commits on the local feature branch.
Push your changes to the remote feature branch.
Create a pull request to merge your changes from the feature branch into the main/develop branch
Approve the changes, and have a build process build your code before merge.
Code automatically merges into the main/develop branch after all requirements are met.