User Tools

Site Tools

Navigation Menu


  • StatusClosed
  • OP-ModePre-Launch
  • LocationN48 - E11
  • Localtime22:26
  • CountdownT-00D 00:00

Hot Projects


SEEDStack - Open 3D printable seed/sprouting systemDIY Food Hacking


UCSSPM - Unified Clear-Sky Solar Prediction ModelOpen Solar Power


picoReflow - DIY PID Reflow Oven Controller based on RaspberryPiDIY Reflow Soldering


PiGI - DIY Geiger Counter based on RaspberryPiRasPi Geiger Counter

DIY ARA-2000

Active Wideband Receiver Antenna for SDR - ARA-2000Wideband Antenna


DSPace - Map everythingMap everything!


HOWTO: Test and merge github pull-requests locally

Today, another pull-request flew in, enhancing the picoReflow software stack with MAX6675 compatibility. Git and github are great tools for open collaboration but it takes some time to get used to them. Of course, the github auto-merge feature is great and works pretty reliable, but I still prefer to review and test PR's locally on the commandline, before actually merging them.

Github also offers some command line foo for this, as you can see in the screenshot above but I'd like to use this opportunity to share another way how to test, handle and merge github pull requests even more easily and comfortably, in case you're new to git/github and don't know about this yet in a real-world, step-by-step example.

Adding pull refs to your .git/config

Just go into the directory where you store the git repo you have received a pull request for and open .git/config in an editor. You'll find a section that looks like this (with your repo names of course).

[remote "origin"]
     url =
     fetch = +refs/heads/*:refs/remotes/origin/*

We just have to add another fetch target so our git knows where to fetch pr's from github:

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Now the section should look like this.

[remote "origin"]
     url =
     fetch = +refs/heads/*:refs/remotes/origin/*
     fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

This has to be done only once per project/repo. Afterwards you can just start with Step 1:

Simple 4-Step Fetch/Test/Merge/Push

Step 1: Fetch & checkout the pull request

When receiving a new pull request on github, you'll get a notification with the pull request's id, like this:

Now we just have to fetch from origin to see if it pops up:

 $ git fetch origin
 * [new ref]         refs/pull/7/head -> origin/pr/7

Good, PR #7 is here and we can just switch over to it (checkout):

$ git checkout pr/7
Branch pr/7 set up to track remote branch pr/7 from origin.
Switched to a new branch 'pr/7'

Step 2: Do your worst (Testing)

Review and test the new code.

Step 3: Merge the pull-request

Once testing is finished and everything seems to be in order, we merge the pull request into the branch we want, in this case the master branch, so let's checkout master:

$ git checkout master

Finally we merge the pull request into the master branch and since github already told us that it could merge the PR automatically, we don't expect to be confronted with any merge conflicts:

$ git merge pr/7
Merge made by the 'recursive' strategy. |   3 +++
 lib/    | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/       |  20 ++++++++++++++++++--
 3 files changed, 146 insertions(+), 2 deletions(-)
 create mode 100644 lib/

Step 4: Push

Now we just have to push it back to github which will automagically mark the pull request as closed/merged and notify the pull request initiator.

$ git push

Done. Easy, right?

Mission-Log entry created by chrono on 2014/12/19 12:09 UTC


Comment text

Please type the letters you see on the left into the box on the right:

   ___    _  __   ___    ___    ___ 
  / _ |  | |/_/  / _ \  / _ \  / _ )
 / __ | _>  <   / ___/ / ___/ / _  |
/_/ |_|/_/|_|  /_/    /_/    /____/