I Have a Pull Request on GitHub, Now What?

Patrick Reagan, Former Development Director

Article Category: #Code

Posted on

I'm a n00b when it comes to Git, so I solicited Matt's help to get the changes in my fork up to our main GitHub account. As awesome as GitHub is, there's still no "automatically-pull-and-merge" functionality when someone wants to send you their changes (and for good reason). Here's how I made it happen:

The Scenario

I wanted to work on my constant_cache gem, so I forked the project into my own GitHub account. I made the changes I wanted, ensured that all specs were passing, committed, and then pushed the changes up to my repository. Now it was time to sync up those changes with the main repository.

The (One of Many) Solution

Following the guide on GitHub got me about 80% of the way, but I needed to employ some additional git-fu to sync things up.

I started by grabbing the latest "official" code and taking a look at the branches that were created:

 $ git clone git@github.com:vigetlabs/constant_cache.git $ git branch # Showing local branches * master $ git branch -a # Shows all branches - local and remote * master origin/HEAD origin/master 

Now I needed to grab the latest changes from my repository, so I added it as a remote source:

 $ git remote add reagent git://github.com/reagent/constant_cache.git $ git remote -v origin git@github.com:vigetlabs/constant_cache.git reagent git://github.com/reagent/constant_cache.git 

Then I created a local branch to start pulling from the remote repository:

 $ git checkout -b reagent/master $ git branch -r master * reagent/master $ git pull reagent master:HEAD 

Since I was the only person working on this I didn't really need to stage any of the changes, so I went straight ahead and merged my changes with my local branch of the main repository:

 $ git checkout master $ git merge reagent/master 

At this point, everything was ready to go. I ran all the specs one last time and then did a final push back to the main repository (I'm back in the 'master' branch now):

 $ git push 

I created a couple of tags along the way, so I needed to get those out there as well:

 $ git push --tags 

Another Approach

Now that I have the hang of things, I've settled on a different approach. Instead of merging changes in from my public clone URL, I'll use the private clone URL so that I can push changes back to both repositories as necessary:

 $ git remote -v origin git@github.com:vigetlabs/constant_cache.git reagent git://github.com/reagent/constant_cache.git $ git remote rm reagent $ git remote add reagent git@github.com:reagent/constant_cache.git $ git remote -v origin git@github.com:vigetlabs/constant_cache.git reagent git@github.com:reagent/constant_cache.git 

I'm now reserving the reagent/master branch for all work done in my personal forked repository:

 $ git branch -d reagent/master $ git checkout -b reagent/master $ git pull reagent master 

As I'm working, I can push changes back out to my GitHub account from my working branch:

 $ git push reagent reagent/master:master 

When the codebase stabilizes and I'm ready to make a release, I can merge into the main branch to get the changes up to the correct account:

 $ git checkout master $ git merge reagent/master 

One caveat: I haven't used this approach extensively, but it seems to work with the limited testing I've done. If you have a different approach that works better, please let me know.

Related Articles