0

I accidentally commited to branch dev, instead of feature-branch, and pushed to the remote. Based on the advice from git undo commit on protected branch?, I took the following steps to undo the commit on dev and commit it to feature-branch

on dev, undo the commit locally and stash it, so I can later commit it to feature-branch:

  1. git reset --soft HEAD~1
  2. git restore --staged .
  3. git stash
  4. git pull
  5. git revert SHA-1
  6. git commit -m "reverting commit made to wrong branch"
  7. git push

on feature-branch:

  1. git stash pop
  2. git add ., git commit -m "making commit in the right place"

Great. At this point, dev is back to where it was before I wrongfully made the commit there, and feature-branch has the new changes. I then did some more work and added more commits to feature-branch.

After creating a pull request from feature-branch to dev and merging it in, it seems the commit that was reverted is not present on dev.

What is happening here?

For now I will just create a new branch and manually rewrite the commit, but I don't comprehend why this series of events has led me to see a diff in my IDE (vscode and gitlens), but github is telling me there is no diff?

Seth Lutske
  • 9,154
  • 5
  • 29
  • 78
  • Off of which commit did you make `feature-branch`? Was it a commit on `dev` before the original commit you reverted, between the original commit and the revert, or after the commit was reverted? – bk2204 Dec 22 '21 at 18:01
  • That's a good question...honestly at this point I can't be sure exactly which way I did it. How would each scenario play out? – Seth Lutske Dec 22 '21 at 18:32
  • Note you can look at `git log --graph` to answer the question from @bk2204 . You'll see exactly which commit you branched off of. – TTT Dec 22 '21 at 22:37
  • It might help if you show `git log --graph` of `dev` after the merge, and then explain what you mean by "the commit that was reverted is not present on dev". – TTT Dec 22 '21 at 22:44
  • 1
    Kind of irrelevant to the question but I think `git stash apply` was probably just `git stash`? Since "apply" would put an existing stash into your working directory and it sounds like you did the opposite, which is just create a new stash from files in your working directory. – TTT Dec 23 '21 at 19:34
  • Regarding the edit, I assume after the merge you can see the "missing" commit in the log twice now, with *different* commit IDs? There should be the original commit and the revert after it, and then another "copy" of it that was on `feature-branch` with a *different* commit ID? And to restate your problem: the *changes* associated with that commit are missing when you checkout the latest version of `dev`? Can you confirm this is true? If yes to all of that, then did you have merge conflicts when you merged `feature-branch` into `dev`? – TTT Dec 23 '21 at 19:37
  • Note, the reason I am emphasizing that the copy of the commit has a *different* ID is because if it was the same ID, it would exactly explain your problem. (Because you can't re-merge in the same commit ID again so it would be ignored in the merge.) But, I don't think that's your problem since you re-committed the changes on `feature-branch` so it would have to have a different commit ID. So just confirming that you see both commits in the log with different IDs. – TTT Dec 23 '21 at 19:40
  • I am tracing back through the log on each branch, and I cannot find 2 independent commits with the content in question. I can see only 1 commit which has the changes, on both branches. I'm not sure how that would be possible since I stashed, popped, and recommited to the new branch. I think I must have done something I don't recall, because there really should be an independent commit on each branch with the same content – Seth Lutske Dec 23 '21 at 20:54
  • @SethLutske Yeah, not sure how you did it, but if the commit ID is the same on both branches, then that would explain the issue. You'll need to make sure you rewrite that commit so it has a different ID. – TTT Dec 24 '21 at 18:19

1 Answers1

1

tl;dr: It appears that you attempted two different solutions for the same problem, and ended up not doing what you think you did.

If you accidentally committed something to dev, and wanted to fix it, you have two (categories of) ways to deal with it:

  1. You can reset back to the previous commit, essentially deleting the most recent commit.
  2. You can revert the commit.

It's not clear whether you had pushed out dev with the errant commit on it, but I suspect that you probably didn't, based on the description. In that case reset would have been the best way to go. Had you already pushed the mistaken commit and others were likely using it already, then revert would have been best. Apparently you tried to do both of these; it looks like you did a reset first followed by a revert.

The first reset "deleted" the commit, and then trying to revert something that isn't there wouldn't work, so you'd be left where you started. (Do you remember seeing any messages to this effect when you tried it?)

Note, had you previously pushed out dev and decided revert was the way to go, after resetting back a commit you wouldn't have been able to do git push without force pushing.

Side note, to move that commit over to feature-branch, you can simply cherry-pick that commit by the hash ID it had on dev, instead of trying to go through the extra work of stashing it, which I suspect is what led you down this path to begin with.

Tip: I highly recommend using git log or git log --graph often. Consider using a UI that displays the branch history and refreshing it after every commit you make so you can see exactly what you're doing, and mistakes will become obvious.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • 1
    "I suspect that you probably didn't [push our dev]" - unfortunately I did push to the remote. I edited the question to reflect that. Also, I adjusted the steps I took. I forgot to mention that after I did a reset, restore, and stash, I did a `git pull`. This was a silly way to stash the commit I needed so I can bring it over to `feature-branch`, while maintaining `dev` consistent between the remote and my local. Yes, `git log --graph` would have been a very good idea in this scenario ¯\\_(⊙_ʖ⊙)_/¯, hopefully these new details make the question clearer – Seth Lutske Dec 23 '21 at 18:53
  • @SethLutske Good edit, the fact that you pulled after the reset makes much more sense. Now I have more clarifications which I'll ask at the question level. – TTT Dec 23 '21 at 19:29