GitHub Pull Requests are useful to manage the workflow of your development with Git. Git offers a native branch management system that makes it easy to work collaboratively. Whether you’re using the
Git-flow model or the
Trunk-Based approach, only the lifetime branch varies: you still rely on branches to integrate new code increments. Pull Request is a facility to validate each increment of code with features
fostering collaboration among developers. We list in this post 10 things to know about Pull Requests.
#1: A Pull Request is automatically updated
In case you’ve created a PR, and another developer added comments and said you should reword your code, what happens? You can perform your code modification on the
source branch and just push your new commits. The Pull Request page will be automatically updated and will display your latest modification. You don’t have to re-create a new PR for that. Note also that any comment made on the source code that has been edited will be marked as
Outdated.
#2: Assign one or more developers to review your code
On the right side of GitHub pull request page, you can request a code review and assign someone responsible for this PR.
The difference is subtle: consider
reviewers as people responsible for
reviewing the code source, suggesting improvements, checking coding standards application,…
assignees will ensure the PR can be merged and will close it.
#3: The display can be customized
Side by side or unified, what do you prefer? On the
Files changed tab, you can easily switch this configuration.
#4: Comments can be added to the source code or the main thread
You can add comments on both
Conversation and
File changed tabs*.* The
Conversation tab lists all the comments within the PR, either on the source code or in the general discussion. Use this tab to ask questions on the PR itself, and use the
File changed tabs to write any comment on specific source code lines.
#5: Link your Pull Request to issues
On the Pull Request page, you can find this section on the right side that allows you to indicate which issues should be closed after the merge request will be closed.
#6: Pull Request and Merge Request are the same thing
You probably heard these two terms already. While GitHub spread the term
Pull Request, GitLab chose a different name,
Merge Request. BitBucket and Azure DevOps also adopted the “Pull Request” name. In any case, be aware they refer to the same exact concept. Each Git platform may have specific implementations, but the basics still remain.
#7: You can close but not delete a Pull Request
You can delete a GitHub issue, but it’s not possible so far to delete a Pull Request. In case of major issues, such as a security breach, you can still rewrite the history or contact GitHub support.
#8: Use third-party tools for automated checks
GitHub has a great
marketplace to connect your projects to third-party providers to automate code analysis or security checks for instance. Once you’ve installed them, their analysis will be triggered as soon as the PR is opened, and they will automatically comment on your Pull Request.
#9 You can use GitHub to resolve conflicts
In case of conflicts within a PR, you won’t be able to merge. In most cases, conflicts can be handled directly in GitHub, using the
Resolve Conflicts button. Find the doc on that topic on the
GitHub website.
#10: Don’t lose your code comments forever, make them a valuable knowledge
If you’re used to code reviews, you may already had this feeling that you’re repeating yourself across reviews. That’s because all your discussions within a PR remain in the PR. There’s actually no capitalization process once the Pull Request is closed.
You can rely on solutions such as
Packmind which offer plugins for your web browser and enrich your experience on GitHub, to convert your code comments into best practices that will fill your team’s knowledge base.
Feel free to share with us some tips about GitHub pull requests!