在 Git 中撤消已推送到远程存储库的特定提交
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/2318777/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Undo a particular commit in Git that's been pushed to remote repos
提问by Lakshman Prasad
What is the simplest way to undo a particular commit that is:
撤消特定提交的最简单方法是:
- not in the head or HEAD
- Has been pushed to the remote.
- 不在头部或头部
- 已推送到远程。
Because if it is not the latest commit,
因为如果不是最新的提交,
git reset HEAD
doesn't work. And because it has been pushed to a remote,
不起作用。而且因为它被推到了远程,
git rebase -i
and
和
git rebase --onto
will cause some problem in the remotes.
会导致遥控器出现问题。
More so, I don't want to modify the history really. If there was bad code, it was there in the history and can be seen. I just want it out in the working copy, and I don't mind a reverse merge commit.
更重要的是,我真的不想修改历史记录。如果有错误的代码,它就在历史中并且可以被看到。我只是希望它在工作副本中出现,而且我不介意反向合并提交。
In other words, what is the Gitequivalent of the following svn commands:
换句话说,以下 svn 命令的Git等价物是什么:
svn merge -r 303:295 http://svn.example.com/repos/calc/trunk
which removes all changes from 295 to 302 by reverse merging all changes in those revisions, as a new commit.
它通过反向合并这些修订中的所有更改作为新提交来删除从 295 到 302 的所有更改。
svn merge -c -302 ^/trunk
which undoes the 302 commit, of course by adding another commit that reverse merges the changes from that respective commit.
这会撤消 302 提交,当然是通过添加另一个提交来反向合并来自相应提交的更改。
I thought it should be a fairly simple operation in Git and a fairly common use case. What else is the point of atomic commits?
我认为这应该是一个相当简单的 Git 操作,也是一个相当常见的用例。原子提交还有什么意义?
We have staging stashingand all to ensure the commits are perfectly atomic, shouldn't you be able to undo one or more of those atomic commits easily?
我们有 staging stashing和所有这些来确保提交是完美的原子性,难道您不应该能够轻松地撤消这些原子性提交中的一个或多个吗?
回答by Andrew Aylett
Identify the hash of the commit, using git log
, then use git revert <commit>
to create a new commit that removes these changes. In a way, git revert
is the converse of git cherry-pick
-- the latter applies the patch to a branch that's missing it, the former removes it from a branch that has it.
使用 确定提交的哈希值git log
,然后使用git revert <commit>
来创建删除这些更改的新提交。在某种程度上,git revert
是相反的git cherry-pick
- 后者将补丁应用于缺少它的分支,前者将其从拥有它的分支中删除。
回答by Thank you
I don't like the auto-commit that git revert
does, so this might be helpful for some.
我不喜欢这样做的自动提交git revert
,所以这可能对某些人有帮助。
If you just want the modified files not the auto-commit, you can use --no-commit
如果您只想要修改后的文件而不是自动提交,则可以使用--no-commit
% git revert --no-commit <commit hash>
which is the same as the -n
这与 -n
% git revert -n <commit hash>
回答by moatPylon
Because it has already been pushed, you shouldn't directly manipulate history. git revert
will revert specific changes from a commit using a new commit, so as to not manipulate commit history.
因为它已经被推送了,你不应该直接操纵历史。git revert
将使用新提交从提交中恢复特定更改,以免操纵提交历史。
回答by Meysam Sadeghi
If the commit you want to revert is a merged commit (has been merged already), then you should either -m 1
or -m 2
option as shown below. This will let git know which parent commit of the merged commit to use. More details can be found HERE.
如果您要还原的提交是合并提交(已经合并),那么您应该选择-m 1
或-m 2
选项,如下所示。这将使 git 知道要使用合并提交的哪个父提交。更多细节可以在这里找到。
git revert <commit> -m 1
git revert <commit> -m 2
git revert <commit> -m 1
git revert <commit> -m 2