So imagine the following the happens (and that we're all using SourceTree):We're all working off origin/develop. I go on holiday for a week.My coworker has been working locally for the past several days without merging origin/develop back in to his local develop branch.He tries to do a push, gets told he has to merge first, and then does a pull.He gets a conflict, stopping the automatic commit-after-a-merge from proceeding.Assuming that Git is like SVN, my coworker discards the new files in his working copy and then commits the merge - wiping those new files from the head of origin/develop.A weeks worth of dev work goes on on top of that revision.I come back from holidays and find out that several days of my work is missing.We're all very new to Git (this is our first project using it), but what I did to fix it was:Rename develop to develop_old.Merge develop_old into a new branch develop_new.Reset the develop_new branch to the last commit before the bad merge.Cherry pick each commit since then, one by one, resolving conflicts by hand.Push develop_old and develop_new up to the origin.At this point, develop_new is, I'm hoping, a good copy of all of our changes with the subsequent weeks worth of work reapplied. I'm also assuming that reverse commit will do odd things on a merge, especially since the next few weeks worth of work is based on it - and since that merge contains a lot of things we do want along with stuff we don't.I'm hoping that this never happens again, but if it does happen again, I'd like to know of an easier / better way of fixing things. Is there a better way of undoing a bad merge, when a lot of work has gone on in the repo based on that merge?
What's the best way to undo a Git merge that wipes files out of the repo?
git
If I understood correctly, this is your situation:    ,-c--c--c--c--M--a--a--X  developo--o--y--y--y--y-After some common history (o), you committed and pushed your work (y). Your coworker (c) did work on his local repository and did a bad merge (M).Afterwards there might be some additional commits (a) on top of M.git reset --hard develop M^2git branch coworker M^1Now your graph looks exactly like before the bad merge:    ,-c--c--c--c  coworkero--o--y--y--y--y  developDo a good merge (G):git checkout developgit merge coworkerResulting in:    ,-c--c--c--c-o--o--y--y--y--y--G  developNow transplant the additional commits:git reset --hard Xgit rebase --onto G M developThis gives the final result:    ,-c--c--c--c-o--o--y--y--y--y--G--a--a--X  developBe aware that this might result in more merge conflicts. Also you just changed history, i.e. all your coworkers should clone/reset/rebase to the new history.PS: of course you should replace G, M and X in your commands by the corresponding commit id.