Let's walk through creating a standard Build VM
Part 5 - Pull Requests (PRs)
what is a pull request? how do they work? what do they signify?
Create a Pull Request (PR)
The code is done but not the work. The developer still has to singal that his work is complete. We'll want to create a Pull Request or PR for short. There are 2 ways to do this. The first is in VS, which will just redirect you to Azure DevOps. The second is Azure DevOps. In VS, it can be found here:
In Azure DevOps, go to Repors, select your repo, select your branch then click "create a pull request".
Inside the PR, you can add some details for the PR. Additionally, reviewers and actions can be configured inside DevOps.
Notice you can select what you are creating a PR into. You can set a reviewer or additional reviewer if you'd like. Also notice that the PR is automagically associated with out bug work item. Let's create the PR.
As you can see, it merged successfully on its own and now we, or the approver, can approve and complete. Typically we wouldn't approve our own PRs. We'll see this when we complete.
We'll have an option for the merge type, if we want to use something different. Additionally, we have "complete associate work items after merging" checked as well as "delete bug200 after merging". This will resolve the bug setting it's status to done and deleting the branch we created for the work item called "bug200". Next, click "Complete merge". This is what the bug work item looks like after completing the PR:
The work item's status is "Done". Also note the links section. We can see that we had a commit and PR. However, the link to branch is now gone because the branch itself is gone.
Conclusion
Because Git Branches allow us to pull everything up, rather the push specific changesets like in TFVC, we can more easily keep track of what is where. As a for instance, until bug 200's work gets a completed PR, I know it's only in the branch for that work item.
Blog Main Tag: