Best Way To Merge A (GitHub) Pull Request

by Gerard Sychay

Here at Differential, we’re big believers in open-source, both as consumers and producers. As producers, eventually, others will want to contribute to your project. A few days ago, I asked the following of the Twitterverse.

Anyone have thoughts on the best way to merge a pull request? Use the button on Github? Locally? Fast-forward? Non-fast-forward? etc.

— Gerard Sychay (@hellogerard) May 3, 2013

After briefly scouring the whole of the Internet, I fleshed out three potential methods.

Use the Merge Pull Request Button

The built-in GitHub Merge Pull Request button is certainly the fastest and most convenient solution.

However, depending on when your contributor forked the project, you may get overlapping merge commits, which nobody likes. Here’s an example of that happening (sorry to pick on Slim-Extras):

Plus, I don’t like the thought of code merging behind the scenes without my controlling every step. There must be a better way.

Catch Feature Up with Master by Rebasing, then fast-forward Merge

IMO, open-source Pull Requests should first be checked out locally for review. The actual commands and sequence varies widely, but I typically run the following:

$ git remote add <username> <URL>  
$ git fetch <username>
$ git co -b <pull-request-branch> <username>/<pull-request-branch>

At this point you have the pull request code local and side-by-side with your master branch. You can run tests, diff sets of files, and generally review the changes. If you are satisfied, run git rebase master to rebase your master branch onto the pull request branch. This ensures that any changes you’ve made to your project since the contributor forked a copy is inserted in a clean fashion to the pull request changes.

Now, how to get them into master and close the pull request? You can of course run:

$ git co master  
$ git merge <pull-request-branch>

Since you’ve rebased any recent commits on master onto the pull request branch, merging will fast-foward master. Your history will look like this:

That’s not bad, but now that everything is a straight line, it’s kind of hard to see where the pull request begins and ends. I guess you could look at the author. But what’s so bad about merge commits anyway? You can see who and what was committed in a branch. And why not let branches show up in the branch history?

Catch Feature Up with Master by Rebasing, then merge --no-ff

The third option: prepare your pull request branch as above by rebasing, but after checking out master, the last command becomes:

$ git merge --no-ff <pull-request-branch>  

You’ll get something like the following history:

The two pull requests are easy to see, as are when they were merged. In both cases of merging locally, after you merge a pull request branch and push it back to Github, Github will close the pull request.

In Conclusion

In case u care, answer to my pull request question, I’ve decided to: checkout fork locally, rebase master to fork, merge –no-ff to master.

— Gerard Sychay (@hellogerard) May 4, 2013

Note: some of this merging philosophy was explained recently in Git merge vs. rebase.

Share Share on Twitter Share on Facebook Share on LinkedIn

How Can We Help?

If you’re a middle-market or enterprise level organization with a problem that might be solved through technology, we’d love to set up a 15-minute Discovery Call to see how we might help.

Contact Us