Git: How to point to a previous commit without losing current commit?

Question

I use git in a fairly linear and basic manner, but I ran into an issue that I rarely run into and I am unsure of how to fix.

I committed something too early in one of my branches. It will get launched soon, but I am not ready to have it launched yet. I am trying to figure out the best way to go about having the branch I am working on point to a previous commit before I merge this branch into the master branch, so that when this branch is merged into the master branch it is not referencing the most recent commit.

Using git log (git log --oneline), I have the following:

d17be71 (HEAD -> qa, origin/qa) Fix footer in jsp.
bc6dde8 (featureBranch1) Correct company logo.

So d17be71 was accidentally added to qa, and qa will be merged into master. I don't want these changes to be merged into master, but I don't want to lose them. I want bc6dde8 to be merged into master, and after this code launches successfully, then I will incorporate d17be71 back into qa, then merge that into master, then launch that as well.

Doing some reading on merging, branching, and HEAD:

Branching and Merging

Detached HEAD

Rewriting History

But I'm still a little lost as to what the correct approach should be. I am assuming that I can just point the HEAD to bc6dde8, and that will act as the last commit so that when I merge into master, d17be71 will not be merged into master but still exist on my qa branch, but I haven't read anything that confirms this will actually happen.

I guess I could create a new branch off of qa, then go back to qa and revert back to bc6dde8 and erase my last commit, then merge back into qa after launching, but I am assuming I don't have to do that. Just having a difficult time figuring out what exactly it is I am supposed to do if not that.

How should I go about correcting this mistake?

Answer 1

I guess the simplest solution would be

git checkout master
git merge qa^

(Note the ^, which tells git you're merging the parent commit of the commit referenced by qa.)

In my tests, git sees what I'm doing and even modifies the default merge message to say

Merge branch 'qa'  (early part)

(Of course you could delete the text (early part) if you want this to end up looking (mostly) like the merge had occurred before the excluded commit had been added to the qa branch. Or you could change the commit message in whatever way you normally would for merge commits, for that matter.)

Your solution of creating a new branch and resetting the qa branch also works and isn't that much extra work since git branches are pretty light-weight. (Note the terminology, though; this is a reset. To revert is to create new commits that undo the changes from previous commits. While that is another user's suggested answer, I don't recommend it, because it puts unnecessary clutter in history.[1]) The main trick to doing that is, you'd want the re-merge of d17be71 to be a fast-forward; but that's not such a trick, because it should be the default behavior as long as nothing else is added to qa in the meantime.

There are many other possible solutions as well. A variation on your solution, using the reflog instead of a temporary branch, for example:

git checkout qa
git reset --hard HEAD^
git checkout master
git merge qa
git checkout qa
git reset --hard qa@{1}

---

[1] : There are times when revert makes sense instead of reset. The main reason would be to avoid editing a shared history. But that only really matters if you're going to share the history edit, which isn't the case here because the history edit is temporary.

Answer 2

You could simply git revert d17be71. It won't erase d17be71, but instead generating a reverting commit that essentially cancels out d17be71. Make a note of the hash of that reverting commit. After qa is merged into master, run another git revert the-revert-commit-hash, it'll cancel out the revert, and effectively reinstate the d17be71 changes.