标签云

微信群

扫码加入我们

WeChat QR Code

This question already has an answer here:How to revert a Git repository to a previous commit41 answersI'm not clear on how git revert works. For example, I want to revert to a commit six commits behind the head, reverting all the changes in the intermediary commits in between.Say its SHA hash is 56e05fced214c44a37759efa2dfc25a65d8ae98d. Then why can't I just do something like:git revert 56e05fced214c44a37759efa2dfc25a65d8ae98d


Even though this question is actually older than the one it's now marked as a duplicate of, that one has a better answer. meta.stackexchange.com/questions/147643/…

2019年05月22日50分17秒

This question and the top answer here may confuse git users. Just to help understand the terminology, you don't revert to a commit. You can either reset to a commit (which is like going back in time using time machine) or revert a commit (which is like pulling out a commit as if it never existed - however it does preserve the revert info in history, allowing you to revert a revert if you wanted to)Note also that you shouldn't use the m flag and type a commit message if you get conflicts in the process. The auto message git provides is more informative when looking back in history.

2019年05月22日50分17秒

This is very good feedback. Thanks alexrogins

2019年05月22日50分17秒

alexrogins what does pulling out a commit as if it never existed mean? Not sure what 'revert a revert' refers to either - appreciate the comment though, good info, just looking for more detail on your perspective.

2019年05月22日50分17秒

Joe as in if you add a line of code then commit that line, if you were to revert it you would be undoing that line of code (wherever it was first written in history, doesn't have to be the last commit). That then makes a revert commit. If you revert that revert commit then you're essentially undoing the undo (i.e. redoing the original line again)

2019年05月22日50分17秒

Wouldn't it be equivalent (and one command shorter) to do: git reset --hard 56e05fced as the first command, and then skip the final git reset --hard?

2019年05月22日50分17秒

When I did this I ended up with a bunch of Untracked Files in the working tree.However looking at the history I could see that those files did have a corresponding delete commit in that "Revert to SHA" commit.So after git reset --hard at the end, you can do git clean -f -d to clean up any untracked files that lingered about.Also, thank you so much this helped me solve a crisis!

2019年05月22日50分17秒

do I have to do the git reset --soft HEAD{1} unconditionally? I mean always with a value of 1?

2019年05月22日50分17秒

vemv Yes, unless you want to throw away commits on the tip of the branch. git reset 56e05fced adds another entry to the reflog (run git reflog), so git reset --soft HEAD{1} simply moves the pointer back to the HEAD prior to calling git reset 56e05fced. Using a higher number (e.g. git reset --soft HEAD{2}) would append the new commit on a previous commit. That is, increasing the number would essentially throw away N-1 commits where N is the number you replace 1 with.

2019年05月22日50分17秒

Tom this solutions works. You must have done something wrong, or your reflog might not have any entries in it (if it's a very new clone, for example). Regardless, you'll find more intuitive solutions for "reverting" a branch in this answer.

2019年05月22日50分17秒

In the case that you're history has already been pushed to a remote before you did the hard reset, you would need to force push the newly reset branch with git push -f, but Be Warned that this could possibly unintentionally delete other users' commits, and if not delete new commits, then it will force other users to resynchronize their work with the reset branch, so make sure this is OK with your collaborators first.

2019年05月22日50分17秒

This seems to be the best answer. It also tells clearly the difference between git revert and git reset.

2019年05月22日50分17秒

then I can just merge this with the head? What if I anticipate having TONS of conflicts, can I just force this commit to be the head "as-is" and just overwrite any conflicts?

2019年05月22日50分17秒

I'm not sure what head you're talking about. You can just move your head back to this commit. (for instance by deleting and creating branch). If you want to do a "merge" commit into the head, which is effectively the reversal of the intermediate commits, you can use merge with "ours" strategy. Pick your option and read manpages. The power is waiting for you to use it ;-)

1970年01月01日00分03秒

That makes sense, the reason I ask is that git now tells me that I'm not on any branch.

2019年05月22日50分17秒

because you aren't. if you type git branch you will clearly see it. You can do for instance git checkout -b mybranch 56e05 to get it with branch.

2019年05月22日50分17秒

I think he's asking how to do a fastforward

2019年05月22日50分17秒

Novices should be aware that push -f can destroy history.However, sometimes this is what you want :)

2019年05月22日50分17秒

Sometimes you are really glad that the history is deleted...was looking for this -f option, thks !

2019年05月22日50分17秒

Thanks, to be literal, I had to type in -> git push origin master -f where <reponame> can't just be origin at least for me

2019年05月22日50分17秒

As people have mentioned above, If we want our repo head pointing to a specific commit without maintaining history then use above steps other wise we can use git revert.

2019年05月22日50分17秒

Is there anyway that we know who had reset (i.e rollback commit) and forced push on a specific branch?

2019年05月22日50分17秒

Note that if you're reverting a few hundred commits, this could take a while because you have to commit each revert individually.

2019年05月22日50分17秒

splicer you don't have to revert each commit individually, you can either pass the --no-edit option to avoid having to make individual commit messages, or you can use --no-commit to commit the reversions all at once.

2019年05月22日50分17秒

thelem git revert HEAD..56e05f is entirely the wrong command to use, git revert 56e05f..HEAD already reverts the commits in reverse order to avoid conflicts.

2019年05月22日50分17秒

Cupcake you are right HEAD..56e05f doesn't work for me but 56e05f..HEAD did the trick

2019年05月22日50分17秒

This is by far my preferred way of rolling back, no matter if you pushed it or not. I added this to my global ~/.gitconfig under the aliases section: rollback = "!git revert --no-commit $1..HEAD #" - so now I can just intuitively do $ git rollback a1s2d3

2019年05月22日50分17秒

The -a in your commit isn't necessary.

2019年05月22日50分17秒

Perfect. This should become one single command in the git cli, IMO.

2019年05月22日50分17秒

very nice! this is much better than git revert 56e05fce..HEAD because it's just one commit

2019年05月23日50分17秒

mmm, I take that back, this is simpler: stackoverflow.com/questions/4114095/…

2019年05月22日50分17秒

This isn't correct in general, I'm afraid.The checkout will only (I think) update paths that exist, so if a file has been deleted since 56e05fced, it won't be staged by doing git checkout 56e05fced -- .

2019年05月22日50分17秒

This solution won't delete new files that have been added since 56e05fced , like a git reset --hard or a git revert would. You really want to use those commands if you actually want to restore the state of 56e05fced, not git checkout.

2019年05月22日50分17秒

Note: This will put you in a detached head state. Not advisable!

2019年05月22日50分17秒

This worked for me, but what does "--" mean in this context?

2019年05月22日50分17秒

...and is also very dangerous as will wipe all the history since including other peoples work. Beware of this one!

2019年05月22日50分17秒

This basically does the same thing as git reset --hard 56e05f, except this is less safe and more hacky. You might as well use Charle's solution or Jakub's solution.

2019年05月22日50分17秒