Skip To Main Content

A Git Workflow Walkthrough – Merging Pull Requests

Posted by Jim Vallandingham

Aug 13 2015

We are in the homestretch with our git workflow walkthrough. I knew we could do it! Last time, we looked at a few ways to review pull requests. In this final (for now!) installment, we will merge our reviewed changes back into master.

Once your pull request reviewer is satisfied with the changes, you’ll get the coveted +1 (or equivalent affirmative emoji), which means it’s time to get this thing merged!

Plus One

Additional suggestions, if you feel the scope is small enough, can be dealt with in a separate PR or added as another commit to the existing one. I typically like smaller PRs to bigger ones, so if I can justify splitting out additional suggestions into separate issues, I go that route. A good rule of thumb is to have one PR per issue.

If you are lucky, the PR can be auto-merged, and you can do it right inside GitHub with just a few clicks!

However, sometimes (and not often, honestly) the magic doesn’t quite work, and you need to return to the command line one final time for the merge.

Merge Fail

Luckily, the instructions for getting started are right there and just a click away.

Merge Steps

First, make sure you have the latest master in your local repo.

git checkout master
git pull origin master

Then switch back to the feature branch and merge in master

git checkout docs
git merge master

This should fail, and it should tell you which files you need to look at to resolve the conflict.

Merge Conflict Notes

Here, I just have one file that needs attention: gruntfile.js

After opening it up in my text editor, I look for the <<<< indicating a merge conflict.

Merge Conflict

I modify the code until all of the conflicts are dealt with.The top section, before the equals chain is what was on the remote master branch before your changes came in. The bottom section is your local stuff. Picking out what to keep is a decision only you can make – but I know you’ll make the right one.

Then I add the file to staging.

git add gruntfile.js

The rest of the merge is already in staging, so now I can commit the merge

git commit -m 'merged master'

Once all of the conflicts have been resolved and the commits are made, it’s good practice to double check that none of the conflicts resulted in broken code. This step is particularly important if someone was modifying the same area of code as your PR.

Now, we can switch back to master to merge this PR into the main master branch.

git checkout master
git merge --no-ff docs
git push origin master

This is more work than the auto-merge, but with small feature changes, this manual process is typically the exception to how merging works and not the rule.

An easier approach

Ok, so we went through how GitHub suggests you tackle the problem of merge conflicts. When talking through this process with my co-worker Yannick, he provided a slightly simpler process that he uses to get his pull requests into a mergeable state.

He makes sure the local master is synced up with the remote one, then on the local branch used to generate the pull request, he just merges in the latest version of master.

git fetch origin master
git checkout docs
git merge master

This will cause the merge conflict, same as before. So deal with that as you see fit. Now, after the merging is done, we can push back up to the same docs feature branch, and update our pull request with the merge already dealt with. This means we can use the GitHub functionality to merge it from the website!

Auto Merge

The alternative process has the added benefit of being able to easily test your changes after the merge locally. This gives you greater confidence that the merge went as expected and everything is cool.

Delete remote branch

Either way, once the PR is merged into master, we can remove the remote branch to keep our GitHub project cleaned up.

Delete Branch

You can also remove the remote branch via the command line by running:

git push origin :docs

Note the : prefixing the name of the branch. The : separates the name on your local repository from the name on the remote repository, so :docs means “push nothing to docs” which deletes it.

And we are done!

We’ve covered a lot of ground here. Now you have the full picture of the mighty Pull Request. You can make ‘em, and you can knock ‘em down!

Remember, these processes and workflows are all suggestions and tips rather than hard rules to help you communicate better with collaborators when building new things together. The technical details of the tools we use can obfuscate the fact that, at the end of the day, we are people just trying to communicate with other people in meaningful and effective ways.

With these tutorials, I’ve broken down some of that technical complexity to encourage users to do more with their existing tools and engage in these conversations with their collaborators. I hope these walkthroughs give you the confidence you need to start using feature branches and pull requests to take your Git collaboration skills to the next level.

Git Happy

Comments

We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.

Contact Us

We'd love to hear from you. Get in touch!