This self-paced course will help you prepare for the Azure Developer certification exam AZ-204: Developing Solutions for Microsoft Azure.
In this blog Azure DevOps Branching Strategy, you will learn how you should use branching to support multiple releases and patch versions over a period of time. Git branches aren’t much more than a small reference that keeps an exact history of commits, so they are cheap to create. Committing changes to a branch will not affect other branches, and you can share branches with others without having to merge the changes into the main project. Create new branches to isolate changes for a feature or a bug fix from your master branch and other work.
Branch policies are an important part of the Git workflow and enable you to:
· Isolate work in progress from the completed work in your master branch
· Guarantee changes build before they get to master
· Limit who can contribute to specific branches
· Enforce who can create branches and the naming guidelines for the branches
· Automatically include the right reviewers for every code change
· Enforce best practices with required code reviewers
Code reviews are a best practice for most software development projects. To require teams to review their changes before completing a pull request, select Require a minimum number of reviewers.
The basic policy requires that a certain number of reviewers approve the code with no rejections.
If Requestors can approve their own changes isn’t selected, the creator of the pull request can still vote Approve on their pull request, but their vote won’t count toward the minimum number of reviewers.
If any reviewer rejects the changes, the pull request can’t finish unless you select Allow completion even if some reviewers vote to wait or reject.
You can reset code reviewer votes when new changes are pushed to the source branch. Select Reset code reviewer votes when there are new changes.
Require associations between pull requests and a work item to ensure that changes to your branch have work item management tracking. Linking work items provide additional context for your changes and ensures that updates go through your work item tracking process.
Configure a comment resolution policy for your branch by selecting Check for comment resolution.
Maintain a consistent branch history by enforcing a merge strategy when a pull request finishes. Select Enforce a merge strategy and pick an option to require that pull requests merge using that strategy.
Set a policy requiring changes in a pull request to build successfully with the protected branch before the pull request can be completed.
Build policies reduce breaks and keep your test results passing.
Build policies help even if you’re using continuous integration (CI) on your development branches to catch problems early.
External services can use the PR Status API to post detailed status to your PRs.
The branch policy for additional services brings the ability for those third-party services to participate in the PR workflow and establish policy requirements.
Select reviewers for specific directories and files in your repo.
These reviewers are automatically added to pull requests that change files along those paths. You can also specify an Activity feed message.
There are several permissions that allow users to bypass branch policy.
In Azure DevOps Services, the Exempt from policy enforcement permission does not exist. Instead, there are two new permissions:
· Bypass policies when completing pull requests
· Bypass policies when pushing
Users that previously had Exempt from policy enforcement enabled now have the two new permissions enabled instead.
In some cases, you need to bypass policy requirements. Bypassing lets you push changes to the branch directly or complete a pull request even if branch policies aren’t satisfied.
· Set up permissions to control who can read and update the code in a branch on your GlTrepo.
· You can set permissions for individual users and groups and inherit and override permissions as needed from your repo permissions.
· Remove permissions for a user or group by selecting the user or Azure DevOps group, then selecting Remove.
· The user or group will still exist in your Project and this change will not affect other permissions for the user or group.
· Prevent updates to a Git branch by locking the branch. Locking a branch prevents other users from changing the existing commit history.
· Locking also blocks any new commits from being added to the branch by others.
· Locking is ideal for preventing new changes that might conflict with an important merge or to place a branch into a read-only state.
· Locking does not prevent cloning of a repo or fetching updates made in the branch into your local repo.
· We can restore a deleted Git branch via the web in Azure Repos or TFS 2019.
· If you need to restore a Git branch in your own repo from Visual Studio or the command line, push your branch from your local repo to Azure Repos to restore it.
· Open your repo on the web and select the Branches view.
· Search for the exact branch name using the Search all branches box in the upper right.
· Click the link to search for an exact match in deleted branches. If there is a deleted branch that matches your search, you will be able to see which commit it pointed to when it was deleted, who deleted it, and when it was deleted.
· To restore the branch, select the … icon next to the branch name and then select Restore branch from the menu. The branch will be recreated at the last commit to which it pointed. Note that branch policies and permissions will not be restored.
· The ahead of and behind numbers listed for each branch are in comparison with the branch currently labeled Compare on the Branches page. Update your compare branch to see how far ahead or behind your branches shown on the page are to another branch in your repo:
· Select the … next to the branch you want to set as the baseline for comparison.
· Select Set as compare branch.
· The Compare label will move to this branch and the other branches on the page will have the number of commits ahead/behind updated to reflect the new comparison.
This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts
The central repo holds two main branches with an infinite lifetime:
master branch at
origin should be familiar to every Git user. Parallel to the
master branch, another branch exists called
After, the main branches
develop, our development model uses a variety of supporting branches for parallel development between team members, and tracking of features, production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited lifetime(short-lived), since they will be removed after the work is completed.
The different types of branches we may use are: