What is a pull request?
A pull request (often abbreviated as PR) is a concept invented by GitHub to request that changes you've made in a code branch be reviewed and, if deemed suitable, merged into another branch (typically the main branch). While GitHub coined the term "pull request" and popularized the concept, other version control platforms like GitLab enable similar strategies using different terminology. GitLab for instance, calls them "merge requests", and at organizations using Phabricator, pull requests are referred to as "diffs". Pull requests are central to many collaborative development workflows, such as Git Flow and Stacking.
Key components of a pull request
- Source branch: This is the branch that contains changes or new features that a developer wants to merge into the target branch.
- Target branch: This is the branch to which the changes from the source branch will be merged, often the main or development branch.
- Diff: A pull request includes a diff, short for 'difference', which shows the changes between the source branch and the target branch. This includes additions, deletions, and modifications in the codebase.
- Review: Before merging, pull requests typically undergo a review process where other team members can comment, approve, or request further changes.
How pull requests work
The process of creating and using pull requests involves several steps that facilitate collaboration, code review, and integration of changes.
1. Creating a branch
The first step in making a pull request is to create a branch in the repository where you can safely work on new features or fixes without affecting the main codebase.
2. Making changes and committing
Once you have a branch, you can start making changes to the code. Each set of changes will typically be committed with a message describing what was changed and why.
3. Pushing changes
After committing your changes, the next step is to push the branch with your changes to the remote repository.
4. Opening a pull request
Once the branch is pushed to the remote repository, you can create a pull request. This is done through the repository’s web interface (like GitHub, GitLab, or Bitbucket), where you specify the source branch and the target branch for the merge.
5. Review and discussion
Other team members can view the pull request, comment on the changes, and suggest or make additional commits if necessary. This step is crucial as it ensures the quality and integrity of the codebase.
6. Approval and merge
After the pull request is reviewed and approved by the required number of team members, it can be merged into the target branch. This merge integrates the changes from the pull request into the main codebase.
7. Closure and clean-up
Once merged, the pull request is closed. It's common practice to delete the source branch after the pull request is merged to keep the repository clean.
Why use pull requests?
Pull requests have several advantages in a software development workflow:
- Collaboration: They facilitate teamwork by allowing multiple developers to work on different features simultaneously without interfering with each other’s work.
- Code quality: The review process helps improve the quality of the code, as bugs and issues can be identified and addressed before the code is merged.
- Security & compliance: Code review, facilitated through pull requests, is also important for achieving security and compliance certifications like SOC 2, and ISO.
- Knowledge sharing: They provide an opportunity for team members to share feedback and learn from each other, leading to better overall project comprehension and coding practices.
- History: Pull requests provide a documented history of the changes made to the codebase and the rationale behind them.
To get the most out of your pull request workflow, learn how to stack your pull requests on top of one another, allowing you to skip the wait of code review.
