Reputation: 267
I have what should be a simple case but it's mystifying me and I've not found anything in any of the other answers here that actually works.
I've got a couple of merges to master
that I want to roll back. The end result I want is master
to be set back the way it was before these commits, so I can then push from a known good branch to ensure that master
shows only prod-released code.
Here is the log:
my.username@mysystem MINGW64 /c/Git/REPOSITORY (master)
$ git log --oneline
e6a1eed (HEAD -> master, origin/master, origin/HEAD) Merge pull request #26
from PROGRAM/revert-24-int_project_2.1.0
b9b82f0 (tag: PROGRAM_project-2.0.0, origin/int_project_2.0.0,
int_project_2.0.0) Revert "Merge pull request #24 from
PROGRAM/int_project_2.1.0"
c4a6573 Revert "PROGRAM_project_2.0.0"
c3aa6d1 (tag: PROGRAM_project_2.0.0) Merge pull request #24 from
PROGRAM/int_project_2.1.0
**b7e583a** (tag: project_tag_2.1.0_01) Merge pull request #23 from
PROGRAM/dev_project_2.1.0
**54ecb7a** June 2.1.0 release.
**b67f981** Merge pull request #22 from PROGRAM/int_project_2.0.0
f9b81bc (tag: project_tag_2.0.0_04, origin/int_project_2.0.0fix,
int_project_2.0.0fix) Merge pull request #21 from PROGRAM/dev_project_2.0.0
Here is the results of my attempts to revert the merges (I got one merge (#24) reverted already, but found later that there were two more that needed to go (#22 and #23). Here's what happened when I tried to revert:
my.username@mysystem MINGW64 /c/Git/REPOSITORY (master)
$ git revert -m 1 b7e583a
On branch master
Your branch is up to date with 'origin/master'
nothing to commit, working tree clean`
At one point it complained that I had changes in the remote repo that were not in the local, which shouldn't be the case for master
branch since nothing should be pushed to that branch except under specific circumstances, so I'm not sure why git should care what's happening in other branches. I did a pull
and that complaint went away, but I'm afraid a pull would overwrite my revert by bringing down the very commits I'm reverting.
I'm relatively new to git and github so I've got a lot of gaps in understanding to fill, and in this case, I'm probably missing some fundamental piece or pieces of knowledge that are generally assumed to be known by more experienced git users.
Upvotes: 4
Views: 1063
Reputation: 1779
In git you can discard unwanted commits in 2 ways: you can revert them or you can delete them by removing them from your branch's history.
Removing the commits is the neatest way of tidying up, but if other users are working on the branch and have already pulled the unwanted commits, they will repush them next time they push. It can also get confusing for them when they try and pull and find upstream history has changed. For this reason it's generally not recommended to do this on shared / public branches.
If this is ok, to reset history and discard to a known good point:
git reset --hard <good commit>
git push -f origin HEAD
Reverting creates a new commit which counters the bad commit. This is safe to do on a branch which is shared with others but leaves "messy history".
What you have done looks correct. The fact that revert doesn't seem to do anything suggests to me that maybe some of the merge commits you're trying to revert were maybe encompassed in a previous revert?
A sure fire way of doing a revert-ish operation to get your code to exactly match a given point in time would be to checkout at that point, back up the files, go back to the branch you want to repair, copy the files over the top and commit that. It will match exactly and git will only commit files with differences (ie it will have the same effect as a revert).
git checkout -b temp-branch <good-commit>
<copy files somewhere>
git checkout -
<copy files over workspace>
git add .
git commit
Make sure you don't copy the .git
dir. There are ways to actually avoid the copying here by using more arcane git commands, such as git read-tree
but the above is easy to understand.
Good luck!
Upvotes: 1