Pull Requests

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:

$ git checkout -b feature/header

Next, let’s make a change and commit:

$ git add index.html
$ git commit -m "Add page header"

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:

$ git checkout master
$ git pull upstream master
$ git checkout feature/header
$ git rebase master

We’ll make another change and commit on our feature branch:

$ git add index.html css/style.css
$ git commit -m "Make header responsive"

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:

We fix this locally and push to the fork again:

$ git checkout feature/header
$ git add index.html css/style.css
$ git commit -m "Format code"
$ git push

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.