To maintain the quality of your app, you can define policies that must be met before changes from the developer can be integrated into the selected branch.

Mostly, the policy is defined on the master branch, but it could be any branch you want to keep healthy. If you define the policy for a branch, changes cannot be pushed into this branch directly, but only through Pull Requests (PRs). See the Pull request section for more details. In this way, each change is checked and tested, and if the policy is not met, the change will not make it into the branch. You can define the following in the policy:

• The minimum number of reviewers: This is how many reviewers must approve the PR to be accepted.
• Check for linked work items: This forces developers to associate the PR with work items to have links between requirements and changes.
• Check for comment resolution: If the reviewer wrote some comment, the comment must be resolved before the PR is accepted.
• Enforce a merge strategy: You can prohibit a fast-forward merge (you lose some detail but gain simplicity) or enforce a squash merge, which will condense all commits from the developer into one new commit on the target branch.
• Build validation: You can define a build pipeline that will be used to build and test the changes. If the build succeeds, the PR could be accepted. Failing the build may prevent the PR from being accepted (optional behavior). In this way, you can keep the branch healthy.
• Automatically include code reviewers: This defines user groups or users that will be used as reviewers by default. Reviewers could be chosen by specific changes, for example, when a script file or the settings of the app are changed, the responsible person will be added as a reviewer automatically.

Some developers tend to view branching policies as just additional hurdles in their way, but it is a great opportunity to grow your team and improve the quality through the reviews. It gives the team a chance to learn from each other and teach themselves new things. And additional eyes on the code are always good.