How to Handle a Pull Request from GitHub
We decided to pick up Git for the Vanilla & Garden projects after discussions we had with people from many other companies while we were in TechStars this past summer. Git is still a bit of an enigma to me, and I’ve been receiving pull requests from people for a while, and I’ve failed to successfully get their changes into my code – instead opting to just manually apply their changes with my own IDE. That is, of course, a total waste of my time and contrary to the entire purpose of us adopting Git. So, today I finally sat down and dug my way through to figure out how to handle a pull request.
After a few hours of frustration, it finally makes sense. Here’s the long and short of it: Define the user’s remote repo, get a local copy of their work, go into the branch you want to pull their changes into, and cherry pick their commit into your branch.
Here are the actual commands I used to accomplish this for a number of different pull requests today:
Step 1. Do you already have their repo set up as a remote branch on your dev machine? Check with:
git remote -v
If not, add the remote branch and fetch the latest changes with:
git remote add -f <username> git://github.com/<username>/Garden.git
Note: “Garden” is the name of our project on github. Obviously, you would need to substitute that for your project name.
2. Do you already have a local copy of their repo? Check with:
git branch -a
If not, create it and check it out with:
git checkout -b <username>/master
If you do already have a local copy of their repo, fetch the latest changes:
git fetch <username>
3. Get their changes into your personal working branch:
git checkout master git cherry-pick <hash of user's specific changes that they requested you to pull>
That’s it. I can’t believe it took me so long to figure that out!
For your next trick will you show me how to pull/push a local copy of the code to my fork of Garden and how to keep it in sync with your dev branch?
I’m equally stranded on all things Git/version control and I’ve spent days trying to figure it out.
@Lincoln – Now that you mention it, that would be a really good idea for an entry on the wiki.
Right now I’m trying to get a bunch of fixes and changes in place for a push to master later today. I’ll see if I can squeeze this in afterwards.
I’m fairly sure I sent this earlier this summer
http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
The first one is free and talks about pull requests.
Note that when you check out ‘username/master’, that’s not (strictly speaking) a local branch. In fact it’s a ‘remote tracking branch’, which is automatically updated when you fetch from their remote repository. In other words, you don’t need to manually update the remote tracking branches.
So you can replace your
git checkout /master
git pull master
git checkout master
git cherry-pick
with just
git fetch username
git cherry-pick
assuming that you are already on your local master branch.
Oh, rookie error, the comment system ate my angled brackets! That should have been:
You can replace your
git checkout [username]/master
git pull [username] master
git checkout master
git cherry-pick [hash of user's specific changes that they requested you to pull]
with just
git fetch [username]
git cherry-pick [hash of user's specific changes that they requested you to pull]
Awesome – thanks, Chris!
Actually, Pulling is simply creating a merge.
This page explains a very, very simple way of doing it (if you just want to merge all the changes)
http://github.com/guides/pull-requests
@Chacha – The only problem with their method is that it doesn’t describe cherry-picking. And I only cherry-pick.