标签云

微信群

扫码加入我们

WeChat QR Code

This question already has an answer here:

On Git, say I mess up my commits, and I want to make the version 3 commits ago as the new version. If I do git checkout xxxx, it creates a new branch and it seems like I can only merge it? Could I make this the new "master version"?

I want:

A-B-C-D-E

to become

A-B-C-D-E-F

where F has exactly the same content as C

If I use git revert xxxx instead, it seems like it definitely will have conflicts and I need to manually resolve it.

What I really want is just make the old commit at some point the new commit, regardless of what's in my working directory or the latest commit.

How would I go about doing this?


No, just git checkout XXXXX. rev~n means n revisions before rev.

2018年09月24日40分58秒

The dot after HEAD~3 is important.

2018年09月24日40分58秒

this works but I feel like there should be a more elegant way to do this.

2018年09月25日40分58秒

with a large repo it takes awhile to delete all of the files and then check them all back out. I feel like git should have a way to revert to an old revision without having to delete everything. But that's just my opinion, this worked well for me and I didn't see a better way when I was looking for alternatives.

2018年09月24日40分58秒

Is it possible to use a specific commit ID?

2018年09月24日40分58秒

Hi thanks for the answer. But what if I don't want to do the hard reset since it's already pushed onto a public repository?

2018年09月25日40分58秒

huggie Ah. Then you probably want to use the revert method

2018年09月24日40分58秒

then git push -f to force push

2018年09月24日40分58秒

Does this maintain commit "E" and create a new commit, "F"?

2018年09月25日40分58秒

meetalexjohnson The revert method does; revert makes a new commit that is the opposite of the commit you specified, so they cancel out. The first revert would make F that's the opposite of E, and the second would make G that's the opposite of D, so you end up with the same code you had at C. That's why the second revert is HEAD~2 instead of HEAD~1 -- F is the head commit after the first one, so you need to go 2 back to refer to D

2018年09月25日40分58秒

This causes rejection when pushing to origin.

2018年09月25日40分58秒

This works for me. Pushing to origin wasn't a problem.

2018年09月25日40分58秒

so git checkout <commit-hash> will detach HEAD (push gets rejected), git checkout <commit-hash> . should checkout . (all changes) from the commit to your working-tree, which you can apply as a new commit. You can also detach HEAD and branch off that commit. It should then be at HEAD for the new branch and you can commit there. The . is important.

2018年09月24日40分58秒

git cherry-pick C takes the changes introduced by C and applies them on top of E. This is not what the OP asked for. He wants to have the files in the exact state that they were in C, which git checkout provides.

2018年09月24日40分58秒

Vote down. 1. the question explicitly asks for keeping older commits, so that might be a reason why other answers attempt to do that. 2. as you said, the commits might have been published and there's no need to introduce comments on what that means with rebasing.

2018年09月24日40分58秒