Submit a Pull Request

After pushing your branch to ADO, it's now time to integrate your changes into the main application. This occurs through the pull request (PR) feature in ADO, which brings in changes from a source branch to a target branch.

Create the pull request

Once you login to ADO Repos, you should see a banner that you recently published changes to a branch. Follow that link and continue the steps to create a pull request. Otherwise, you can select Pull Requests from the ADO Repos menu and click New pull request.

• Be sure to select your branch to merge into main
• Provide an appropriate title and description of the changes
• Add members from your team as reviewers
• Because we created a branch from the work item, that link should already exist (otherwise you will need to add that link for the PR gate)

Make sure you update the target repository. By default, a forked repository will try to push changes back to the upstream (original) repository. Change the target to your fork.

Wait for reviewers and check status, and then action as necessary

Collaborating over code changes during a PR is a critical part of a team's way of working and agreeing on integrating new changes to the application. It is a vital space to discuss implementation details, coding standards, best practices, and suggestions.

Before changes can be merged in, all merge checks must pass. This gating mechanism is a built-in safety measure to ensure all changes have been vetted and approved before merging in. This includes typical standards like reviewers must approve and the PR must be associated to work items. There can be additional gates depending on team and project norms.

PR reviewer instructions

Reviewers should thoughtfully and carefully analyze the changes in the PR. This includes browsing the various tabs in the PR, like Files, Updates, and Commits. Make sure to compare the changes against the work item to validate that the acceptance criteria was met, and that nothing additional was included.

Reviewers may also checkout the branch locally by running git pull and then checkout out the branch they are reviewing. This is not an uncommon practice, especially during pairing and debugging.

Provide appropriate comments in the PR and then provide a response or Approve or Reject or any option that is appropriate. Your response can be changed if the PR is updated.

Reviewers can approve or reject changes. Additionally, they can make comments that require a resolution before merging in. All of these gates help provide safety nets for teams to enable and protect their application's quality, security, and standards.