Get feedback with pull requests
Pull requests combine the review and merge of code into a single collaborative process. Once a feature is added or a bug is fixed, the developer creates a pull request to begin the process of merging the changes into the upstream branch. Other team members are then given the opportunity to review and approve the code before it is accepted. Use pull requests to review works in progress and get early feedback on changes. There's no commitment to merge the changes as the owner can abandon the pull request at any time.
Get code reviewed
The code review done in 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 these problems before the merge, protecting important branches from unwanted changes.
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 assigning reviewers to a pull request, make 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 running in it. Reviewers should make an effort to provide feedback on changes they don't agree with. Identify the issue and give a 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, accepting suggestions or explaining why they decline to apply them. Sometimes suggestion are good, but may 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 the team relies on always being in good shape, such as
main branch. Teams can require pull requests to make any changes on these branches on platforms like
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.
GitHub has extensive documentation on proposing 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.