Git：有没有办法找出提交是从哪里挑选出来的？

Question

如果我从多个分支中挑选，是否有一种简单的方法可以找出提交来自哪里（例如原始提交的 sha）？

示例：
- 在主分支
- 从开发分支挑选提交 A
- A 在主分支上变成 D

之前：

* B (master) Feature Y
| * C (dev) Feature Z
| * A Feature X
|/
* 3
* 2
* 1  

之后：

* D (master) Feature X
* B Feature Y
| * C (dev) Feature Z
| * A Feature X
|/
* 3
* 2
* 1  

是否有可能发现 D 是从 A 中精心挑选的（除了搜索提交消息之外）？

编辑：
虽然我会进行daggy-fixes（参见VonCs的答案），但我接受了Chris Johnsens的答案，因为它更接近实际的问题。谢谢你们。

Answer 1

默认情况下，有关原始“cherry”提交的信息不会记录为新提交的一部分。

在提交消息中记录源提交

如果您可以强制使用特定的工作流程/选项，
gitcherry-pick 有 -x 选项：

记录提交时，在原始提交消息中附加一条注释，指示此更改是从哪个提交中挑选出来的。

如果您不能依赖使用该选项的樱桃采摘者，这显然是没有用的。
另外，由于记录的信息只是纯文本——就 Git 而言并不是实际的引用——即使您使用 -x，您仍然需要采取措施来确保原始提交是保持活动状态（例如，它是标签或非倒带分支的 DAG 的一部分）。

gitcherry 和 git patch-id

如果您可以将搜索限制在历史 DAG 的两个特定分支，那么 gitcherry 可以找到“未采摘”和“采摘”的樱桃。

注意：此命令（以及相关的git patch-id）只能识别单独采摘且没有额外更改的无冲突樱桃。如果在挑选樱桃时发生冲突（例如，您必须稍微修改它才能应用），或者您使用 -n/--no-commit 来阶段额外的更改（例如，一次提交中有多个樱桃），或者提交的内容在采摘后被重写，那么您将不得不依赖提交消息比较（或 -x 信息，如果它被记录）。

gitcherry 并不是真正设计来识别采摘樱桃的来源，但我们可以稍微滥用它来识别单个樱桃对。

给定以下历史 DAG（如原始海报的示例）：

1---2---3---B---D  master
         \
          A---C    dev
# D is a cherry-picked version of C

您将看到类似这样的内容：

% git cherry master dev
+ A
- C
% git cherry dev master
+ B
- D

_{（A、B、C 和 D 是真实输出中的完整 SHA-1 哈希值）}

如果看到每个列表中都有一颗樱桃（- 行），它们必须形成一对樱桃。 D 是从 C 中挑选出来的（反之亦然；你不能仅通过 DAG 来判断，尽管提交日期可能会有所帮助）。

如果您正在处理多个潜在的樱桃，您将必须“推出自己的”程序来进行映射。对于任何具有关联数组、散列、字典或等效项的语言，代码都应该很简单。在 awk 中，它可能如下所示：

match_cherries() {
    a="$(git rev-parse --verify "$1")" &&
    b="$(git rev-parse --verify "$2")" &&
    git rev-list "$a...$b" | xargs git show | git patch-id |
    awk '
        { p[$1] = p[$1] " " $2 }
    END { 
            for (i in p) {
                l=length(p[i])
                if (l>41) print substr(p[i],2,l-1)
            }
        }'
}
match_cherries master dev

对于一个有两个采摘的樱桃的扩展示例：

1---2---3---B---D---E  master
         \
          A---C        dev
# D is a cherry-picked version of C
# E is a cherry-picked version of A

输出可能如下所示：

match_cherries master dev
D C
E A

_{(A、C、D 和 E 是完整的 SHA-1真实输出中的哈希）}

这告诉我们 C 和 D 代表相同的更改，E 和 A 代表相同的更改。和以前一样，除非您还考虑（例如）每个提交的提交日期，否则无法判断每对中的哪一个是“第一个”。

提交消息比较

如果你的樱桃不是用 -x 采摘的，或者它们是“脏的”（有冲突，或添加了其他更改（即使用 --no-commit > 再加上暂存额外的更改，或者使用 git commit --amend 或其他“历史重写”机制）），那么您可能不得不依靠不太可靠的比较提交消息的技术。

如果您可以找到提交消息的某些部分，这些消息可能是该提交所独有的，并且在由樱桃选择产生的提交中不太可能发生更改，则此技术效果最佳。最有效的部分取决于项目中使用的提交消息的样式。

一旦您选择了消息的“识别部分”，您就可以使用 git log< /em> 查找提交（也在 Jefromi 的答案中进行了演示）。

git log --grep='unique part of the commit message' dev...master

--grep 的参数实际上是一个正则表达式，因此您可能需要转义任何正则表达式元字符 ([]*?.\)。

如果您不确定哪些分支可能保存原始提交和新提交，您可以使用 --all 如 Jefromi 所示。

Answer 2

如果我按照你的图表，你想知道你是否可以确定D（而不是B）是挑选A的结果。

理论上，如“如何列出包含给定提交的 git 分支？"，您可以搜索提交，如果 D实际上与 A 具有相同的提交 (SHA1)：

git branch --contains <commit>

但正如 Jefromi 评论所述，在这种情况下 D 不能具有相同的 SHA1。
这就留下了对常见提交消息的搜索：请参阅 Jefromi 的回答。

---

正如 Ken Bloom 在问题评论中提到的，对于这样一个本地的樱桃采摘，一种 daggy-fix 技术（如 单调 或 mercurial) 更合适，因为它会留下清晰的合并痕迹。

Daggy 修复意味着使用而不是丢失祖先图中错误和修复之间的真实起源和关系。

由于 [Git] 提供了在任何修订之上进行提交的能力，从而产生一个微小的匿名分支，因此樱桃采摘的可行替代方案如下：

• 使用二等分 识别出现错误的修订版；
• 查看该修订版；
• 修复错误；
• 并将修复作为引入错误的修订的子版本提交。

这个新的改变可以很容易地合并到任何有原始错误的分支中，而不需要任何粗略的挑选滑稽动作。
它使用修订控制工具的正常合并和冲突解决机制，因此它比挑选（其实现几乎总是一系列怪诞的黑客）可靠得多。

（这里是 Mercurial 图，但是轻松应用于 Git）

一直进行糟糕的修复并不适合所有人。
直接针对引入错误的修订版开发修复程序并不总是那么容易。

• 也许直到其他一些更新的代码以暴露该错误的方式使用该错误时才发现该错误；如果没有其他代码，将很难调试并找到修复程序。
• 或者也许当时根本没有意识到修复的重要性或范围。

---

另请参阅这篇文章以了解有关 daggy-fix 的更多信息：

这种返回技术历史上修复错误，然后将修复合并到现代分支中，Monotone，一个有影响力的分布式版本控制系统。
这些修复被称为“daggy”，因为它们利用了项目的历史记录，其结构为有向无环图，或 dag。
虽然这种方法可以与 Subversion 一起使用，但与分布式工具相比，它的分支是重量级的，使得 daggy-fix 方法不太实用。这强调了这样一个想法：工具的优势将影响其用户所采用的技术。

Answer 3

新创建的提交中没有嵌入有关原始提交的信息，因此没有直接的方法可以判断。您建议的（搜索提交消息）可能是最好的方法 - 它肯定比搜索具有相同差异的提交容易得多：

git log --grep="<commit subject>" --all

当然，除非提交不再可以从分支访问......那么您可能会想查看 git fsck 的输出。