Git Tips: Getting out of a bad merge

Matt Reimer
North Arrow Research
2 min readDec 23, 2016

Here’s a problem: You’ve just done a git pull without realizing that someone else had pushed something while you were working. What you end up with is an unintended “Merge” commit that git adds for you.

There’s nothing inherently bad about this and the code is technically the same but it introduces an unintended diversion in the subway map which makes the workflow hard to follow. It also adds unnecessary commits. If there were 8 people working on this project and they all caused this it would get out of hand quickly.

How does this happen?

There are a couple of ways you could get yourself into an bad merge:

1. Pulling before you rebase.
2. Pulling in a non-fast-forwardable way.
3. Merging on purpose but then immediately regretting it.

How do I fix it?

The good news is that if you haven’t pushed yet it’s an easy fix:

git reset — hard HEAD~1

Let’s break this down: git reset will move your HEAD, — hard will reset all files on your system as well as resetting the git HEAD pointer. HEAD~1 is a shorthand for “wherever HEAD is minus one.”

Some Caveats

  • Make SURE you don’t have any uncommitted changes. If you do they will go away forever.
  • Make sure your HEAD is where you think it is.
  • Understand that your merge is going away without any traces. This is usually fine because a typical merge should contains no unique “work”.

--

--

Matt Reimer
North Arrow Research

Maker and doer of things, software developer, fiddle enthusiast.