Git merge madness ends up reverting all developers' work for two days: how to get it back?

A cow-orker of mine did a series of merges (9 开发者_C百科commits and 2 reverts) and as near as I can tell, he has unwound all the code changes for the past two business days. I can identify the last good commit and I can git checkout it. What is the recommended practice for nuking the mergery and returning to a good state -- git revert on each of his unreverted commits? git reset hash --hard?

---

Reverting merge commits can be tricky - especially if they were evil merges, which it sounds like these were. If you can get away with it, it's easier to just blow them away. There are two big options there:

• git reset --hard <good-commit>. This will require some coordination, since any other developers who pulled the bad branch will also need to reset --hard (and if they've done work since pulling, they have to be careful to preserve that, and so on). If your coworker was trying to do something good, you could potentially redo his merges - but do them right this time!

• Manually revert to before the merges. From the top level, git checkout <good-commit> ., then git commit - be sure to write a good message describing what you've just done. You're making a commit that restores everything to that good state, but keeps all the history since then, so that people can hopefully cleanly pull. If you do this, note that as far as Git's concerned, you have still merged whatever your coworker merged. If some of those merged commits were actually good work, and you still want to include them, the easiest thing would probably be to cherry-pick them on top of your manual revert commit.

Finally, if both of those are unsatisfactory - if you don't want to blow away history, but you also want to reintegrate some of what your coworker tried to merge, but not by cherry-picking... you could go for a combination of the two. The idea is to still make that manual revert commit on top of master, but to do it to the state that the merges should have resulted in, instead of the state right before the merges.

# create a new branch, starting from the good commit
git checkout -b temp <good-commit>

# redo the merges, but do it right
# make sure your work tree is how you want it after the merge(s)
git merge ...  

# switch back to master
git checkout master

# get your work tree into the good state
git checkout temp .

# and commit that
git commit