Get feedback with pull requests

  • Article

Pull requests support reviewing and merging code into a single collaborative process. Once a developer adds a feature or a bug fix, they create a pull request to begin the process of merging the changes into the upstream branch. Other team members are then given a chance to review and approve the code before it's finalized. Use pull requests to review works in progress and get early feedback on changes. But there's no commitment to merge the changes. An owner can abandon a pull request at any time.

Get code reviewed

The code review done as part of a pull request isn't just to find obvious bugs; that's what tests are for. A good code review catches less-obvious problems that could lead to costly issues later.

Code reviews help protect the team from bad merges and broken builds that sap the team's productivity. Reviews catch problems before the merge, protecting important branches from unwanted changes.

Code reviews also encourage and strengthen collaboration and communication between developers. And the team gains a clear history of all changes made between the main branch and the feature branches.

Cross-pollinate expertise and spread problem-solving strategies by using a wide range of reviewers in code reviews. Diffusing skills and knowledge makes the team stronger and more resilient.

Give great feedback

High-quality reviews start with high-quality feedback. The keys to great feedback in a pull request are:

  • Have the right people review the pull request.
  • Make sure that reviewers know what the code does.
  • Give actionable, constructive feedback.
  • Reply to comments in a timely manner.

When you assign reviewers to a pull request, be sure to select the right set of reviewers. Reviewers should know how the code works, but also include developers working in other areas so they can share their ideas.

Provide a clear description of the changes and provide a build of the code that has the fix or feature working in it. Reviewers should make an effort to provide feedback on changes they don't agree with. Identify the issue and give specific suggestions on what could be done differently. This feedback has clear intent and is easy for the owner of the pull request to understand.

The pull request owner should reply to comments, accept suggestions, or explain why they decline to apply them. Some suggestions are good, but might be outside the scope of the pull request. Take these suggestions and create new work items and feature branches separate from the pull request to make those changes.

Protect branches with policies

There are a few critical branches in a repo that teams rely on always being in good shape, such as the main branch. Teams can require pull requests to make any changes on these branches with platforms like GitHub and Azure DevOps. Developers pushing changes directly to the protected branches will have their pushes rejected.

Add additional conditions to pull requests to enforce a higher level of code quality in key branches. A clean build of the merged code and approval from multiple reviewers are some extra requirements often employed to protect key branches.

Learn more

GitHub has extensive documentation on how to propose changes to your work with pull requests.

Read more about giving great feedback in code reviews and using pull request templates to provide guidance to your reviewers. Azure DevOps also offers a rich pull request experience that's easy to use and scales as needed.