仅使用git-restore<commit_hash>是行不通的。显然,必须指定-m。


当前回答

正确标记的答案对我有用,但我必须花一些时间来确定发生了什么。所以我决定为我这样的情况添加一个简单明了的答案。。

假设我们有分支A和B。您将分支A合并到分支B中,并将分支B推到自身,因此现在合并是它的一部分。但是您希望返回到合并之前的最后一次提交。。你是做什么的?

转到git根文件夹(通常是项目文件夹)并使用git日志您将看到最近提交的历史记录-提交具有提交/作者/日期财产,而合并也具有合并属性-因此您可以这样看它们:提交:<commitHash>合并:<parentHashA><parentHashB>作者:<Author>日期:<Date>使用gitlog<parentHashA>和gitlog<ParetHashB>-您将看到这些父分支的提交历史记录-列表中的第一个提交是最新的获取所需提交的<commitHash>,转到git根文件夹并使用git checkout-b<newBranchName><commitHash>,这将从合并前选择的最后一次提交开始创建一个新分支。。瞧,准备好了!

其他回答

所有的答案已经涵盖了大部分内容,但我还要加上我的5美分。简而言之,恢复合并提交非常简单:

git revert -m 1 <commit-hash>

如果您有权限,可以将其直接推送到“主”分支,否则只需将其推送到“还原”分支并创建拉取请求。

您可以在此处找到有关此主题的更多有用信息:https://itcodehub.blogspot.com/2019/06/how-to-revert-merge-in-git.html

正如Ryan所提到的,git-restore可能会使合并变得困难,因此git-restore也许不是您想要的。我发现在这里使用git reset-hard<commit hash before merge>命令更有用。

完成硬重置部分后,可以强制推送到远程分支,即git push-f<remote name><remote branch name>,其中<remote name>通常被命名为origin。从那时起,如果您愿意,可以重新合并。

在git-restore-m中,-m选项指定父编号。这是需要的,因为合并提交有多个父级,Git无法自动知道哪个父级是主线,哪个父级就是要取消合并的分支。

当您在git日志的输出中查看合并提交时,您将看到其父级列在以merge开头的行中:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

在这种情况下,git revert 8f937c6-m 1将获得8989ee0中的树,而git rever-m 2将恢复7c6b236中的树。

为了更好地理解父ID,可以运行:

git log 8989ee0 

and

git log 7c6b236

有时,回滚的最有效方法是后退并替换。

git日志

使用第二个提交哈希(完整哈希,在列出错误之前要恢复到的哈希),然后从那里重新广播。

git checkout-b newbranch<HASH>

然后删除旧分支,将新分支复制到原来的位置,然后从那里重新启动。

git branch -D oldbranch
git checkout -b oldbranch newbranch

如果已广播,则从所有存储库中删除旧分支,将重做的分支推到最中心,然后将其拉回到所有存储库。

Ben已经告诉过您如何恢复合并提交,但您必须意识到这样做非常重要

“…声明您永远不希望合并带来的树更改。因此,以后的合并只会带来由不是先前还原的合并的祖先的提交引入的树更改,这可能是您想要的,也可能不是您想要的。”(git merge手册页)。

从手册页链接的文章/邮件列表消息详细说明了所涉及的机制和注意事项。只需确保您理解,如果您恢复合并提交,您不能只是稍后再次合并分支并期望相同的更改返回。