Learn Version Control with Git
A step-by-step course for the complete beginner
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
$ 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.