Software Engineering Asked on January 2, 2022
So imagine the following the happens (and that we’re all using SourceTree):
We’re all very new to Git (this is our first project using it), but what I did to fix it was:
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?
We had the same thing happen. To make matters worse, we work with documentation files and not software, so compiles don't fail and the problem goes undetected for weeks until someone lays eyeballs on something and recalls that something should be there but isn't.
Here was our starting graph when the problem was noticed:
t1--t2--c1--c2--c3 t3--t4--t5..cM--t6--t7--t8 ("master")
c1..c3 is two weeks of the coworker's local work.
cM is the bad merge that effectively undid our team's work of
t3..t5 during that same two weeks.
t6..t8 represents another two weeks of work on top of the bad merge.
I'm still learning Git, but I approached this a bit differently. I created and checked out a new temporary "reapply" branch at the head of "master" at
git checkout -b reapply
and the graph looks like this:
t1--t2--c1--c2--c3 t3--t4--t5..cM--t6--t7--t8 ("master") ("reapply")
I cherry-picked the undone commits
t3..t5 into the "reapply" branch:
git cherry-pick t3^..t5 --allow-empty-message
(I'm not worried about commit messages because I squash everything from "reapply" into "master" at the end.)
If the cherry-pick runs into a conflict, I use
git status to report the conflicting files, resolve the conflicts manually, then do
git add <conflicted_files> git commit -m '' --allow-empty-message git cherry-pick --continue --allow-empty-message
to continue. When cherry-picking completes, I check that the missing commits have been reapplied past the end of "master" in "reapply" with
git log --decorate --oneline --graph master^..reapply
and the graph should look like this:
t1--t2--x1--x2--x3 t3--t4--t5..xM--t6--t7--t8 ("master") r1--r2--r3 ("reapply") / / / ------------------/ / / ------------------ / -----------------
Now, I move back to "master", squash-merge the reapplied changes
r1..r3 from "reapply" into a single commit with a suitable comment, and delete the "reapply" branch:
git checkout master git merge --squash reapply git commit -m 'reapply all changes lost by commit "xM"' git branch -D reapply git push
Now the graph looks like this:
t1--t2--x1--x2--x3 t3--t4--t5..xM--t6--t7--t8--t9 ("master") ^ | ("reapply" squashed into a single commit)
and everyone in the team gets the work back next time they pull.
Would this have worked if our coworker discarded some but not all changes from
t3..t5? In other words, is cherry-picking smart enough not to reapply a change that's already there? I'm not sure.
I don't know if this is the best solution. Other replies mention merging and rebasing in ways that I don't understand. But this was step-by-step, and I could understand what was happening, and it got us through this situation and I'm thankful for it.
Answered by chrispitude on January 2, 2022
It's good that you're thinking about how to fix the repository, but if your coworker only deleted new files and didn't overwrite a lot of updates, then a much simpler approach would be to simply restore the files that were deleted.
I'd probably start by trying to just cherry-pick (onto the current head) the original commits in which you added the code that has now gone missing. If for whatever reason that doesn't work, just check out the old revision with the files you added, and re-add them in a new commit.
What you describe is actually a subset of a well-known Git anti-pattern, which for the life of me I cannot remember the name of - but the gist of it is, making any "manual edits" during a Git merge (i.e. edits that aren't actually resolving any merge conflicts but are making some totally unrelated change) is considered an extremely bad practice because they are essentially masked by the merge itself, and are easily overlooked in code reviews or debugging sessions.
So definitely explain to your coworker that this was an epic fail, but consider slapping on a band-aid before prepping for major surgery.
Answered by Aaronaught on January 2, 2022
If I understood correctly, this is your situation:
,-c--c--c--c--M--a--a--X ← develop o--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^2 git branch coworker M^1
Now your graph looks exactly like before the bad merge:
,-c--c--c--c ← coworker o--o--y--y--y--y ← develop
Do a good merge (G):
git checkout develop git merge coworker
,-c--c--c--c-、 o--o--y--y--y--y--G ← develop
Now transplant the additional commits:
git reset --hard X git rebase --onto G M develop
This gives the final result:
,-c--c--c--c-、 o--o--y--y--y--y--G--a--a--X ← develop
Be 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
X in your commands by the corresponding commit id.
Answered by michas on January 2, 2022
1 Asked on October 29, 2021 by hh54188
2 Asked on February 28, 2021 by stevanity
1 Asked on February 26, 2021 by toshakins
1 Asked on February 23, 2021 by enlico
0 Asked on February 19, 2021 by newbiesoftwarer
0 Asked on February 17, 2021 by leonardo
2 Asked on February 16, 2021 by mcarthey
1 Asked on February 12, 2021 by tlp
0 Asked on February 11, 2021 by lee-alderdice
4 Asked on February 9, 2021 by miguel-stevens
1 Asked on February 8, 2021 by jcode
1 Asked on February 7, 2021 by alec-sanger
1 Asked on February 1, 2021 by jojomatik
0 Asked on February 1, 2021 by brandon-gibson
2 Asked on February 1, 2021
1 Asked on January 31, 2021 by simon-h
Get help from others!