132

I was rebasing code in git, I got some merge conflicts. I resolved the conflicts and did:

git add

At this point I forgot to do:

git rebase --continue

I continued coding and did:

git commit

for the changes. Now I am on "no branch" and can't do:

git rebase --continue

How do I fix this?

t j
  • 7,026
  • 12
  • 46
  • 66
Abhilash
  • 1,562
  • 2
  • 10
  • 10

4 Answers4

249

Just do git reset --soft HEAD^. It moves the HEAD pointer to its parent but keeps the work tree and adds the merge change to the index. So you can continue rebasing with git rebase --continue as before.

kirikaza
  • 2,659
  • 2
  • 15
  • 14
  • 1
    This totally worked, and was also the first time I found a use for --soft. Nice to know how it works, thanks! – mmocny Jan 30 '13 at 18:12
  • 1
    I hope people will see all the up votes on this answer and follow what is suggested here! – Raghu Mar 27 '17 at 05:01
  • 1
    This is exactly what I thought (but may have passed hard by accident). Wasn't sure if HEAD was being updated during a rebase though. Thank you for confirming! So glad I scrolled a bit further before messing with the headache above. – Andrew Wynham Dec 06 '17 at 13:25
  • I edited the accepted answer to put a link down here- I didn't see this answer until after I followed the directions above. – xaxxon Jun 12 '19 at 21:24
  • Is it necessary to use the `--soft` here if I do `git add` later? I just bumped into this issue and did `git reset HEAD~` without reading this answer on stackoverflow first. Any chance I might have broken something I didn't notice? – SOFe Oct 22 '21 at 07:08
11

EDIT: Look at the answer below as well to see if that's an easier solution for you. https://stackoverflow.com/a/12163247/493106

I'd have to try it out, but I think this is what I would do:

  1. Tag your latest commit (or just write down its SHA1 somewhere so you don't lose it): git tag temp
  2. git rebase --abort
  3. Do the rebase again. You'll have to resolve the merge again. :(
  4. git rebase --continue
  5. git cherry-pick temp

The problem with this is that your temp commit probably contains both the resolution of the merge, and the new code. So it could be tricky but I would try it and see if it works.

nikib3ro
  • 20,366
  • 24
  • 120
  • 181
Tyler
  • 21,762
  • 11
  • 61
  • 90
  • Either you can tag like @MatrixFrog says or you can save it as a patch too. Then do the rebase abort. Check the status to make sure the repo is in a state that you know had no problems and then start the fetch and rebase. – yasouser Jun 23 '11 at 17:33
  • 19
    Don't do this. See kirikaza's answer below for a much simpler/cleaner way. Don't mess with cherry-pick and resolving conflicts a second time. – tandrewnichols Dec 05 '13 at 18:24
  • 4
    @Abhilash Please accept kirikaza's answer. I (as did tandrewnichols) did this and there was a much easier way (and the internet seems to agree as that answer has 4x the upvotes). – David Doria Nov 18 '16 at 14:19
  • It's now 10x the upvotes... also, use git rerere to remember your conflict resolutions (useful, unless you sometimes make bad resolutions that you don't want it to remember). – Ajax Oct 10 '18 at 19:30
0

I got the same problem, and to make it worse, I was rebasing three commits, and after solving conflicts on the second commit, I "committed" instead of "rebase --continue".

As a result I had this git reflog

When I applied kirikaza's solution, I just reverted the third commit, and not the second one, which was problematic..

As you can see, the rebase starts by a checkout from the remotes/origin/master branch and then applies my three commits that appear as the three previous operation (before the checkout) in the reflog.

Then, if you want to restart from a clean base, before the rebase, you can simply reset hard to the hash just before the checkout of the rebase operation. In my case (see the picture):

git reset --hard 859ed3c

Then you can start a new git rebase.

Louis Durand
  • 187
  • 9
0

I had git rebased, fixed conflicts, git added file with conflicts, and (mistakenly) committed.

I tried the git reset --soft HEAD^ and git reset --hard solutions given, but neither worked for me.

However, just git rebase --abort worked: it took me back to before the start of the rebase with a clean working tree.

remnantkevin
  • 11
  • 1
  • 1