A pull request is a way to ask for the changes in one branch (or any commit, really) to be integrated into another. Here's a practical example.
Just like forking, pull requests are a convention provided by Git hosting services, rather than a feature in Git itself. While there is a command git request-pull, this is a different thing. GitHub and Bitbucket provide a pull request feature, while GitLab refers to a similar feature as “merge requests”.
A pull request is a way to ask for the changes in one branch (or any commit, really) to be integrated into another. The names come from the fact that, doing a pull request, we’re asking someone to pull from a certain branch to another, merging the branches.
In addition to the above, services provide a variety of features under the name “pull request”. Here are some examples:
The creator of a pull request can often ask for a code review from other developers
The interface for managing a pull request often allows for discussing the pull request
The pull request author or someone else can push further commits to the branch to be merged, updating the pull request
You can certainly have a workflow with a single repository, doing your work in a feature branch and then making a pull request to merge that into the master branch, for example. However, this means you need write permissions to that repository in order to push your feature branch to it. In a fork-based pull request workflow, you push the feature branch to your fork, then make a pull request asking for this to be integrated into the original repository.
A Practical Example
Let’s look at an example continuing on from where we left off last chapter. We had created a local clone of our fork and added the original repository as a remote called upstream. Now, we will create and checkout a new feature branch:
Let’s say that at this point, the master branch of the upstream repository gets updated. In the long run, we certainly want to keep our local clone updated, so any new branches can build on the latest code. Moreover, what if the upstream update touches the same code as the feature we are working on? For a variety of reasons, we may want to rebase our feature branch on the upstream master branch. This is why we added the upstream remote. Using this, we can checkout the master branch of our clone, pull from upstream, checkout the feature branch, and rebase that on the updated master branch:
Finally, we’ll push our feature branch to our fork, to prepare for making the pull request. I’ll add the -u option to make my local branch track the remote branch.
$ git push -u origin feature/header
Note that at this point, the feature branch in our fork repository is up-to-date, but the master branch is not. We can update that from our clone as well:
$ git checkout master
$ git push
To create the pull request, we locate the feature/header branch inside our fork on GitHub and click the “New pull request” button, next to the branch dropdown on the left:
I get to choose the base branch of my pull request, which in this case is the master branch on the upstream, original repository — this is where I’d like my changes to be merged. I can also write a title and a comment for my pull request, request reviewers and more:
At this point, the maintainer of the repository makes a comment on the pull request: we should format our code according to some guidelines:
Now, the commit shows up in the pull request as well:
The maintainer now decides to merge the pull request, hitting the “Merge pull request” button in GitHub. That’s it! The pull request page shows that my branch has been merged, and my code is now part of the original repository on GitHub. At this point, I can delete my feature branch.
Get our popular Git Cheat Sheet for free!
You'll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.
As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.
Just like with Tower, our mission with this platform is to help people become better professionals.
That's why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.