撤消 Git 中已推送到远程存储库的特定提交
撤消特定提交的最简单方法是什么：
- 不在头部或 HEAD
- 已被推送到远程。
因为如果不是最新的提交，则
git reset HEAD
不起作用。而且因为它已经被推送到了遥控器，
git rebase -i
并且
git rebase --onto
会导致遥控器出现一些问题。
更重要的是，我真的不想修改历史。如果有错误的代码，它就存在于历史中并且可以被看到。我只想将其放在工作副本中，并且我不介意反向合并提交。
换句话说，以下 svn 命令的 Git 等效项是什么
svn merge -r 303:295 http://svn.example.com/repos/calc/trunk
：通过反向合并这些修订中的所有更改作为新的提交，从 295 到 302 的所有更改。
svn merge -c -302 ^/trunk
这会撤消 302 提交，当然是通过添加另一个提交来反向合并来自相应提交的更改。
我认为这应该是 Git 中相当简单的操作，也是一个相当常见的用例。原子提交还有什么意义呢？
我们有暂存存储以及所有确保提交是完全原子的，应该您不能轻松撤消其中一个或多个原子提交吗？
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 Git equivalent of the following svn commands:
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.
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.
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?
We have staging stashing and all to ensure the commits are perfectly atomic, shouldn't you be able to undo one or more of those atomic commits easily?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
因为它已经被推送了，所以你不应该直接操纵历史。
git revert将使用新的提交来恢复提交中的特定更改，以便不操纵提交历史记录。Because it has already been pushed, you shouldn't directly manipulate history.
git revertwill revert specific changes from a commit using a new commit, so as to not manipulate commit history.如果您要恢复的提交是合并提交（已合并），那么您应该使用
-m 1或-m 2选项，如下所示。这将使 git 知道要使用合并提交的哪个父提交。更多详细信息可以在此处找到。git revert <提交>; -m 1git revert <提交>; -m 2If the commit you want to revert is a merged commit (has been merged already), then you should either
-m 1or-m 2option as shown below. This will let git know which parent commit of the merged commit to use. More details can be found HERE.git revert <commit> -m 1git revert <commit> -m 2使用 git log 识别提交的哈希值，然后使用 git revert创建删除这些更改的新提交。在某种程度上，
git revert与gitcherry-pick相反——后者将补丁应用到缺少补丁的分支，前者将补丁从缺少补丁的分支中删除。有它。Identify the hash of the commit, using
git log, then usegit revert <commit>to create a new commit that removes these changes. In a way,git revertis the converse ofgit 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 revert 的自动提交功能，因此这可能对某些人有帮助。
如果你只想修改文件而不是自动提交，你可以使用
--no-commit，它与
-n相同I don't like the auto-commit that
git revertdoes, so this might be helpful for some.If you just want the modified files not the auto-commit, you can use
--no-commitwhich is the same as the
-n