I am rebasing branch2 onto a newer version branch1. There were some conflicts so I made the merge and git add
ed the conflicted file. But then instead of doing git rebase --continue
I pressed up on my terminal and without thinking pressed enter to git rebase --skip
. Will the conflict be successfully resolved, Or would git revert back to one of the versions due to the --skip
flag?

- 635
- 2
- 14
- 27
1 Answers
The rebase code is rather tricky (and in 2.13, interactive rebase is mostly handled by the sequencer now, rather than by git-rebase--interactive.sh
, although that's driven from git-rebase--interactive.sh
). Fortunately --skip
is pretty straightforward, being partly handled in the top level shell script, git-rebase.sh, here and here. Using --skip
makes Git run git reset --hard HEAD
before proceeding on to the skip action for the specific type of rebase (am
, interactive
, or merge
: the first two use git rerere clear
for interactive and merge rebases, and the last uses git am --skip
for am
-style non-interactive non-merge rebases).
What this means is that Git threw out your careful resolutions and went on to try to cherry-pick the next commit, and continue the rebase from there.
If you put a lot of work into these resolutions, you can try to recover the now-dangling blob (see Recover dangling blobs in git—note that the accepted answer says to use git show
on the hash IDs, which works, but if you have many to search through, it's simpler to look in the .git/lost-found/other
directory; the added merged files will be in there, mixed in with every other dangling blob remaining in your repository, which could be quite a few). You probably want to abort or undo your rebase as well.
Note that you can save the end product, or product-so-far, of this rebase. That may be useful if you have other good resolutions here. Simply set a branch or tag name to point to the current HEAD
commit before doing either:
git rebase --abort # if it's still in progress, or
git reset --hard ORIG_HEAD # if it's finished now
to go back to the state you had before you started this whole rebase thing. You can then refer to existing finished rebase parts using name~<number>
to count backwards from that commit, or run git log <name>
to find the rebase-copied commits with their resolutions, and cut and past their hash IDs.
-
For quick solution - check the 2 lines of code from this answer. – Eduard Aug 13 '18 at 16:19