With a git workflow, you become used to commands like [cci]git add filename[/cci] and [cci]git commit -m “add filename”[/cci]. When you maintain an open source project and get a pull request, the exact workflow may get murky. How do you review the pull request work? How do you accept the commit if it passes muster?

This post will cover how to review, accept, and close a GitHub pull request.

In our example, we are the creator of a popular open source project called breakfast-sandwich. In our rush to get the product out, we forgot a critical piece – the breakfast sandwich has no cheese! Luckily, our project is open source and we’ve already received a pull request to add cheese to our sandwich.

Here’s the ingredients [cci]list.txt[/cci] file initial state, missing cheese:

[cc]# ingredients list
* english muffin
* eggs
* sausage [/cc]

Here’s the pull request on GitHub:

1. Add the fork’s pull request repo as a remote

[cc]$ git remote add xta https://github.com/xta/breakfast-sandwich.git[/cc]

You can verify that the remote [cci]xta[/cci] has been added by running the [cci]git remote[/cci] command.

2. Fetch the git data from remote

[cc]$ git fetch xta
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/xta/breakfast-sandwich
* [new branch] add-cheese-to-list -> xta/add-cheese-to-list
* [new branch] master -> xta/master[/cc]

3. Checkout the remote branch

[cc]$ git co xta/master
Note: checking out ‘xta/master’.
You are in ‘detached HEAD’ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at be7c26d… add cheese to ingredients list[/cc]

4. Checkout to a new test branch

[cc]$ git co -b “test-add-ingredient”
Switched to a new branch ‘test-add-ingredient'[/cc]

5. Test the current branch

For this step, you would need to perform whatever steps your project deems appropriate before accepting a pull request.

We can open up [cci]list.txt[/cci] and see that it now contains cheese:

[cc]# ingredients list
* english muffin
* eggs
* sausage
* cheese[/cc]

As the updated ingredients from [cci]xta/master[/cci] pass our critiera, we need to merge it back into master branch.

6. Check your feature branch against master to make sure any merge conflicts happen in your feature branch

[cc]$ git rebase master
Current branch test-add-ingredient is up to date.[/cc]

7. Merge feature branch into master

First, switch to master branch:

[cc]$ git co master
Switched to branch ‘master'[/cc]

Then merge the feature branch into master.

[cc]$ git merge test-add-ingredient
Updating 5004985..be7c26d
Fast-forward
list.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)[/cc]

8. Push your master onto GitHub

Great job! We’ve reviewed the feature branch, merged it into master locally. So now, we need to make sure the internet has access to our open source breakfast sandwich that includes cheese.

[cc]$ git push
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 343 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github-xtatest:xtatest/breakfast-sandwich.git
5004985..be7c26d master -> master[/cc]

When you look at your GitHub repo, you’ll see that the pull request is now closed. Most importantly, our breakfast sandwich has cheese!