How to handle your first Pull Request on GitHub?

Question

I'm relatively new to Git. My knowledge thus far includes git add push commit. That's about it, and until now it served me well enough. :)

However this morning someone sent me a pull request, which as I've read means someone forked my repository, made some tweaks and is flagging me saying, "Hey Sergio, I made some improvement. Consider them for the master branch."

Am I correct?

https://github.com/sergiotapia/CherryTomato/pulls

If so, how do I easily merge this users changes into the master branch of the repository? What commands do I need to fire? More importantly, can someone explain the process in layman terms to what has to happen?

Thank you.

Answer 1

You have the right idea. if that set of changes looks useful to you then you probably want to merge it into your repository.

Github offers a nice guide to responding to pull requests: https://help.github.com/articles/using-pull-requests I'd start with that and see if you have any more specific questions about the process.

Answer 2

Github provides a Fork Queue screen that allows you to pull the changes into your repo directly on Github. This screen presents each forked commit in either green or pink depending on whether it will apply cleanly, and allows you to specify a new branch in your repo to merge the changes into. The URL for the fork queue is http://github.com///forkqueue

Update: Use the following steps to merge the Pull Request into your master repository:

$ git checkout master
$ git remote add nakor git://github.com/nakor/CherryTomato.git
$ git fetch nakor
$ git merge nakor
$ git push origin master

Adapted from Github documentation here: http://help.github.com/pull-requests/#merging_a_pull_request

Alternatively, you can use the new "Merge Pull Request", a new feature added to Github today(!): https://github.com/blog/843-the-merge-button

Answer 3

One thing not mentioned explicitly in the GitHub pull request guide is how said pull request should be applied to your code:
I would like those changes to be merged:

• in a fast forward manner (that is simply moving the HEAD of my branch to the next n commits part of the patch)
• or at least without any conflict (the patch only modify/remove lines I haven't touched locally or add new lines)

If there is the slightest conflict, it is best to reject the patch, asking for the sender to pull your own code again, resolve any conflict locally in his/her repo and make a new pull request.
That way:

• they do the work ("they" being the ones sending you "pull requests", that is patches)
• you profit ;)

Answer 4

Many years later, there are new solutions, as found on this page. When in your local git repository, do:

gh pr checkout PRID

where PRID is the pull-request (PR) number or url (e.g. "1" for the first PR). This adds the code from the PR as a new branch to your local repo. It uses the the gh command from the GitHub cli package and only works for active PRs.

Without that package and/or for inactive PRs, you can do the same with:

git fetch origin pull/PRID/head:NewBranchName
git checkout NewBranchName

This adds the PRID code as a new branch named NewBranchName to your local repo. Note that this works without using the repository from the user who submitted the PR, which means it also works if the user('s repo) no longer exists or is unresponsive.

You can now locally check, compare, test and edit the new branch and e.g. merge it with master. Alternatively, you can push the new branch to GitHub with e.g.:

git push origin NewBranchName

This allows you to create a new PR from the new branch (to replace the original PR) and have it reviewed and merged instead.