My team is working with git for the first time and has really messed up our git remote due to our inexperience. I'm trying to help educate them on git to solve the problem in the long term, but in the meantime, the commits that have been made are totally wrong. We haven't made very much progress at all, and I don't see the value in retaining these commits when they could cause confusion/additional problems down the line.

The most recent commit was a merge between the master branch and a second branch that one of the team members unintentionally created. If I try to revert, git states that I must be using the -m flag, but I'm not sure whether I should be reverting or trying to rebase in this case, or how I would do it given the structure of the past couple of commits.

What is the best way to resolve this issue and how should I go about doing it?

  • 1
    Is it possible to see git log --graph --oneline --decorate? You can remove sensitive info from the graph log. Do you want to just throw commits away? Using revert instead of reset or rebase will save you the trouble of trying to sync everyone up, because all that they have to do is a normal fetch and merge. If you force people to sync with a reset or rebased branch, that is feasible, but could be a lot of work to coordinate. Commented Apr 4, 2014 at 20:37
  • recommended reading: Where does my git question go?
    – gnat
    Commented Apr 4, 2014 at 20:43
  • @Cupcake, I'll check it out :] Thanks! gnat, Thank you; That helps!
    – Jsess
    Commented Apr 4, 2014 at 21:08
  • Jsess, @Cupcake was asking for some more information about the structure of your git commits so that it would be possible to address exactly what is necessary to fix your repository.
    – user40980
    Commented Apr 4, 2014 at 21:25
  • @MichaelT I was unable to access my workstation for a while and didn't want to simply ignore the comment - thanks for letting me know. I commented on Dr. Ibb's answer with what I did to attempt to resolve the issue - I tried resetting and then force pushing my change, and that appears to have worked.
    – Jsess
    Commented Apr 4, 2014 at 21:51

2 Answers 2


To undo the merge, you can do

git checkout master
git revert -m 1 [SHA of the merge commit]
git push

This will create and push a new commit which reverts all changes that were merged in.

It's also possible to alter master's history so that it appears as if the merge never happened, but I wouldn't recommend it. Your teammates would have trouble when they try to pull master and the history is different. Also it's easy to revert a revert commit if you reverted the wrong changes, but if you alter mater's history, it's harder to undo that.

  • After doing this, do I need to simply revert the additional non-merge commits? I'd heard something about reverting merges giving incorrect feedback with respect to the commits that were originally merged together. Are there any side-effects to this that I need to be aware of?
    – Jsess
    Commented Apr 4, 2014 at 20:44
  • Were the other commits part of the merge or separate? If separate then yes, you'd need to git revert [SHA] each one. Commented Apr 4, 2014 at 20:55
  • I've managed to successfully revert the merge, but reverting additional commits afterward fails with "could not revert <commit>." After looking up the error, I'm seeing that I need to "resolve the merge" before doing the revert, but I'm having trouble understanding what needs to be resolved. It's clear to me that when you're pulling files that conflict you need to resolve merges because you're "moving forward," but because revert seems to be an undo, I'm not sure I see what merge I need to resolve before reverting.
    – Jsess
    Commented Apr 4, 2014 at 21:22
  • 1
    In some cases you can avoid conflicts by reverting the most recent change first, then the next most recent, etc. But if there are good commits mixed in with bad commits and they touch the same files, there may be "real" conflicts that you need to resolve manually. Commented Apr 4, 2014 at 22:01
  • 3
    @Jsess This command creates a new commit that is the exact reverse of the SHA given to it. If any of the commits that from after the original merge happened to touch the same lines, the conflict is: when revert looks at the code it's trying to revert, the code no longer matches the state the code was in immediately after the original merge.
    – Izkata
    Commented Apr 5, 2014 at 2:05

I believe you're looking for the git reset command. If you run git log it will show you a commit history for your repo. Then run git reset --hard HEAD-number of commits you'd like to go back.

Documentation here: http://git-scm.com/docs/git-reset

  • I'd seen that but was unsure how to get these changes to apply to the remote branch so that they could be passed on to each of the team's local repos. Do you have any additional information that might apply to that? Thanks so much!
    – Jsess
    Commented Apr 4, 2014 at 20:33
  • You may find this question useful: stackoverflow.com/questions/1377845/…
    – Dylan R
    Commented Apr 4, 2014 at 20:43
  • I see - if I'm understanding correctly, it looks like I could reset to the commit that I wanted, then force push to the remote branch. Would this have the behavior that I was expecting? As far as best practice, is this or revert preferred?
    – Jsess
    Commented Apr 4, 2014 at 20:47
  • It's been awhile since I've had to deal with this but I believe that doing a force push will get you where you want to be. reset --hard is sort of a last resort option, as it will wipe out pretty much everything, if I recall correctly. git revert is a little less aggressive and will show as an additional item in the repo's history, so you can revert the revert if needed.
    – Dylan R
    Commented Apr 4, 2014 at 20:56
  • 1
    You may also find this helpful (especially the reset and revert sections): onlywei.github.io/explain-git-with-d3
    – Dylan R
    Commented Apr 4, 2014 at 21:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.