1

I did a dumb thing with git. I had (good) loocal changes to file_a, which I had committed but not pushed. My coworker made (bad) changes to file_a, which she then pushed. I pulled her changes, and rebased them in without fully realizing what was going on. Now file_a is hopeless borkered up, and I'm not sure how to fix it.

Obviously, in the future, pushing more often is one key. What I'd like to do now is undo the rebase, and redo it more thoughtfully. I want to make sure I don't lose my local commits, though, and I'm not sure how to do that.

If I do this command: git reset --hard ORIG_HEAD, will that preserve my two local commits? Or should I do something else?

Update:

I ended up finding the good commits using the reflog. Then, I cherry-picked them in using another branch and verified that everything was working as expected. Then I used git revert fix_rebase_branch --hard in my original branch.

J Jones
  • 3,060
  • 4
  • 26
  • 43
  • 2
    Possible duplicate of [Undoing a git rebase](http://stackoverflow.com/questions/134882/undoing-a-git-rebase) – Wander Nauta Jun 20 '16 at 16:09
  • I looked at this question, but it didn't fully clarify for me whether or not I would lose my local commits, or how to get those local commits back. – J Jones Jun 20 '16 at 16:10
  • This looks like a big ugly mess to me. I also think you are confused about how rebasing works. If you rebased your work on the (incorrect) remote branch, then your two commits should be sitting right there on the HEAD of your local branch, with possible changes to these commits which may have happened from merge conflicts during the rebase. – Tim Biegeleisen Jun 20 '16 at 16:11
  • 1
    Unfortunately, when you rebased you rewrote your two good commits, which sit on the HEAD of your branch. You should go into the reflog, find the two original good commits, and start from there. You could revert your coworkers commit after pulling it in. – Tim Biegeleisen Jun 20 '16 at 16:17

2 Answers2

2

I would walk back through git reflog and make a new branch (i.e. using git checkout -b <new-branch-name> <orphaned-commit-hash>) from the commit that you want. The rebase will have rewritten your two recent commits, but the originals should still be there in the reference log.

dumbledad
  • 16,305
  • 23
  • 120
  • 273
0

The easy way works only if you have not yet "undone" the rebase, nor done much else besides look around (so that your current branch is still just the result of the rebase, and there is no un-committed work lying around). This also requires that you not be using rebase's autostash feature, or if you are using autostash, that you manually git stash before step 2, if you have any uncommitted work-tree changes.

  1. Run git branch save-my-rebased-work to create a new branch name pointing to current commit (pick a name that will be obvious to yourself; note that git branch will create this new branch with no upstream set).
  2. Run git reset --hard ORIG_HEAD to undo the rebase and make your current branch (and work-tree) look the way it did before the rebase.

If you have already undone the rebase, use the reflogs to find the rebase's new commits. Remember that what rebase does is to copy your original commits to new copies. Those new copies are retained via the reflogs after a git reset --hard ORIG_HEAD (until the reflog entries expire in a month or so, anyway). The reason to make a new branch name in step 1 is that the originals and copies look almost exactly the same, and are really hard to tell apart in the reflogs.

torek
  • 448,244
  • 59
  • 642
  • 775