GitHub Pull Request: 10 tips to know

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!