Collaborate with pull requests
Pull requests let you tell others about changes you've pushed to a GitHub repository.
Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.
Pull requests are commonly used by teams and organizations collaborating using the Shared Repository Model.
Everyone shares a single repository, and topic branches are used to develop features and isolate changes.
Many open-source projects on GitHub use pull requests to manage changes from contributors.
They help provide a way to notify project maintainers about changes one has made.
Also, start code review and general discussion about a set of changes before being merged into the main branch.
Pull requests combine the review and merge of your code into a single collaborative process.
Once you're done fixing a bug or new feature in a branch, create a new pull request.
Add the team members to the pull request so they can review and vote on your changes.
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 your code reviewed
The code review done in a pull request isn't just to find bugs—that's what your tests are concerning.
A good code review catches less obvious problems that could lead to costly issues later.
Code reviews help protect your team from bad merges and broken builds that sap your team's productivity.
The review catches these problems before the merge, protecting your essential branches from unwanted changes.
Cross-pollinate expertise and spread problem-solving strategies by using a wide range of reviewers in your code reviews.
Diffusing skills and knowledge makes your team more robust 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 promptly.
When assigning reviewers to your pull request, make sure you select the right set of reviewers.
You want reviewers who know how your code works and try to include developers working in other areas to share their ideas.
Also, who can provide a clear description of your changes and build your code that has your fix or feature running in it.
Reviewers should try to provide feedback on changes they disagree with. Identify the issue and give a specific suggestion on what you would do 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 the comments, accept the suggestion, or explain why the suggested change isn't ideal.
Sometimes a suggestion is good, but the changes are 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 your repo that the team relies on always in suitable shapes, such as your main branch.
Require pull requests to make any changes on these branches. Developers pushing changes directly to the protected branches will have their pushes rejected.
Add more conditions to your pull requests to enforce a higher level of code quality in your key branches.
A clean build of the merged code and approval from multiple reviewers are extra requirements you can set to protect your key branches.