如何在 git rebase 期间通过哈希识别冲突提交? [英] How to identify conflicting commits by hash during git rebase?

问题描述

当我使用 git rebase 遇到合并冲突时，我如何根据提交来确定冲突的来源，而不仅仅是文件差异?

When I encounter a merge conflict using git rebase, how can I identify the source of the conflict in terms of commits, rather than just file differences?

我已经知道如何在 git rebase --continue 之前(基本)使用 git mergetool 或 git add，但有时文件之间的差异还不够:我想查看未能应用于工作树的提交日志和提交差异.

I already know how to make (basic) use of git mergetool or git add before git rebase --continue, but sometimes the differences between files just isn't enough: I want to see the commit log and diff of the commit that just failed to be applied to the working tree.

我在其他问题中读到，如果我使用 git merge，git log --merge 会显示父提交.当我遇到冲突并被告知 fatal: --merge without MERGE_HEAD? 时，我还是尝试了它.

I've read in other questions that git log --merge would show the parent commits if I were using git merge. I tried it anyways when I encountered a conflict and got told fatal: --merge without MERGE_HEAD?.

如何识别有问题的提交?

How can I identify the problematic commit?

推荐答案

简答

如果它说

Patch failed at 0001 commit message for F

然后运行

$ head -1 .git/rebase-apply/0001
From ad1c7739c1152502229e3f2ab759ec5323988326 Mon Sep 17 00:00:00 2001

获取失败提交的SHAad1c77，然后使用git show ad1c77查看一下.

To get the SHA ad1c77 of the failing commit, and then use git show ad1c77 to have a look at it.

让我们从这棵树开始:

A---B---C---D
     
      E---F---G

$ git checkout G
$ git rebase D

当发生rebase冲突时，就是

When a rebase conflict occurs, it is a conflict between

• 来自共同祖先(B)的上游变化(C--D)PLUS已经重新定位的变化和已经解决的冲突(E') 对比
• 下一次提交的补丁(F)

• the upstream changes (C--D) from the the common ancestor (B) PLUS the already rebased changes and already resolved conflict (E') versus
• the patch of the next commit (F)

让我们看看会发生什么:

Let's see what happens:

1) A---B---C---D---E'          <- E patched and committed successfully as E'
2) A---B---C---D---E'---       <- failed to patch F onto E'

错误信息如下:

First, rewinding head to replay your work on top of it...
Applying: commit message for F
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging 1.txt
CONFLICT (content): Merge conflict in 1.txt
Failed to merge in the changes.
Patch failed at 0001 commit message for F

首先，您可以看到它是 F，因为出现了提交消息.但是，如果您的提交消息都看起来像foo"、文档"或一些修复"，那么这将无济于事，并且您确实需要 SHA id ad1c77 或补丁的内容.

First, you can see that it was F, because the commit message appears. However, if your commit messages all look like "foo", "documentation" or "some fixes", then this won't help, and you really want the SHA id ad1c77 or the contents of the patch.

当它列出 rebase 冲突时，它会说:

When it lists the rebase conflict, it will say something like:

Patch failed at 0001 commit message for F

现在查看.git/rebase-apply/，你会在那里找到补丁文件0001:

Now look in .git/rebase-apply/, where you will find the patch file 0001:

$ ls .git/rebase-apply
0001          head-name     msg           orig-head     sign
0002          info          msg-clean     patch         threeway
apply-opt     keep          next          quiet         utf8
final-commit  last          onto          rebasing

补丁文件包含原始commit-id

The patch file includes the original commit-id

$ head -1 .git/rebase-apply/0001
From ad1c7739c1152502229e3f2ab759ec5323988326 Mon Sep 17 00:00:00 2001

然后你可以看看那个.

一定有更简单的方法，但这是有效的.

There must be an easier way, but this works.

请注意，补丁失败的事实可能是由于不同的提交(如果您正在重新定位到 HEAD 和重新定位目标的共同祖先).找到那个提交相当复杂，尽管你可以尝试反向执行 rebase 来找到它:

Note that the fact that the patch failed may be due to a different commit (if you are rebasing onto a common ancestor of HEAD and the rebase target). Finding that commit is rather more complicated, although you could try doing the rebase in reverse to find it:

$ git checkout D
$ git rebase G

这篇关于如何在 git rebase 期间通过哈希识别冲突提交?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！