Use pull requests in Git with Azure DevOps
By setting a branch policy, you can enable the usage of pull request. To create a pull request, you can select pull requests in the Repos section. There you can select the blue New pull request button.
Also, when you push changes to a remote feature branch, Azure DevOps automatically detects and suggests creating a pull request.
When you create a new pull request, you need to provide a title and optional a description. In the pull request, you can specify one or more reviewers. You can set default reviewers in the branch policy. Next to the reviewers, you can also link work items. This has the advantage that your pull request is visible within the work item, so you always have a link back. When you finish the pull request, it can automatically set your work item to done.
Once you select the Create button, you're redirected to the pull request detail page. On this page you can see the linked work items, the configured reviewers. It also automatically checks for possible merge conflicts.
At the bottom of the Overview tab, reviewers can add comments to the pull request. The developer can then discuss and resolve this comment. There's also a files tab that displays all the modified files and compares them with the previous version of the branch you're merging into. On the commits tab, you get a list of all the commits coming into your branch. You can find the same information on the updates tab, but it shows you more information on all the actions that happened on that branch.
A reviewer can set the following statuses at the top of the work item:
Approve
Approve with suggestions
Wait for author
Reject
Approve and approve with suggestions continue the pull request process. With suggestions, just indicates that the reviewer approves, but the developer needs to take some suggestions for next developments into consideration. The wait for author status is there when the reviewer added some comments or remarks, and the developer first needs to reply to, or resolve the remarks. So, the process holds until the reviewer changes the status to approved. Reject stops the process of the pull request, and the merge doesn't complete.
You can enable Set auto-complete. This completes the pull request as soon as all requirements are met, and all reviewers approved. It automatically starts the merge. You can also wait and complete the pull request manually.
Once completed, the merge continues, and you have to define the merge type. The options include:
Merge (no fast forward). This performs a three-way merge into a new commit. This is the default merge type. It keeps the history of all the different commits. You can always track back the different commits. The original commit IDs are kept.
Squash commit. Takes all changes from all the commits and combines them in one new commit on the branch. This loses the history coming from the feature branch. So, you can't track the different commits that made up this modification.
Rebase and fast-forward. With rebase, you're redoing all the different commits, but base on another parent commit. With this merge type, you don't get a new commit, but you replay all the commits on the parent commit. These commits have other commit IDs than the original commits.
Semi-linear merge. This rebases but creates a new commit at the end. This option isn't used that much.
The recommended merge type is the normal merge (no fast forward), or if you really don't want to keep a track to all past commits, you can opt for the squash commit.
You can set some post-completion options. The first one is to set the associated work items to done. After merging you don't need the feature branch anymore, so you can safely delete it. And depending on your merge type, you can optionally customize the merge commit message, otherwise Azure DevOps provides a message.