Git Commit during Git Rebase - what really happens

Question

I'm looking for a good description of what happens if one commits during rebase and how this could be 'reverted' in an easy way.

Let's consider a scenario, where a large commit is rebased. During rebase a conflict appears and user begins merging changes. Now, imagine a scenario where you were almost done, but you didn't call git rebase --continue - for whatever reason (be it long weekend or such). The next week you just resumed working, stil during rebase. Finally, you call git commit --amend to append the changes to the last commit and... they end up in the commit you were rebasing into.

Naturally, you can always checkout the commit you started rebasing from and "hack your way thruogh" - say, for example, by trying to copy all the files from your amend, but that may drop the changes that were introduced in the meantime.

Is there a clean, good way to fix this? This is one particular state I should be careful about and I never want to end up in it, but it still happens occasionally - and I end up spending one whole day trying to get things straight.

I would really appreciate all help and suggestions. Thank you!

Answer 1

There are two proposed solutions to this situation.

• The first solution is to rebase final result back onto original base commit. this would require you to resolve similar merge conflicts once again, but when you're done your commit should be back on track.

• Alternative solution, that worked for me, was to branch off the same point as the commit you ammended to (it carries the SHA, which should be used as a checkout base). Then create a new branch and invoke git merge --no-ff --no-commit --strategy=theirs other_branch, where *other_branch* is the one with unfortunate commit.