git - 是否有可能在 merge 之前获得 merge 提交的哈希？

Question

假设我有 2 个分支 - master 和 feature。此外，我有一个 pull 请求，其中包含 2 次从功能到主控的提交。
如果我 merge 它，我将有一个 merge 提交。
这个提交在 merge 之前已经以某种方式配置了吗？我可以看看它吗？我知道我可以获得 refs/pull-requests/1/from 和 refs/pull-requests/1/merge 分支的哈希值，但是我可以得到类似“merge ”提交的信息吗？

Answer 1

首先，让我们回答你不知道该问的问题

... I know that I can get hash of refs/pull-requests/1/from and refs/pull-requests/1/merge branches, but can I get something like "merge" commit?

这些不是 Git 功能，而是 Bitbucket 功能。 (其他一些 Web 服务可能使用相同的技术，但我在这里假设使用 Bitbucket。)参见 https://community.atlassian.com/t5/Bitbucket-questions/Difference-of-refs-pull-requests-lt-ID-gt-merge-and-refs-pull/qaq-p/772142 (并注意该问题答案中的注意事项)。

这两个在技术上不是分支，只是这取决于我们如何定义分支这个词。见 What exactly do we mean by "branch"?但它们是提交哈希 ID。 refs/pull-requests/1/from 给出的哈希 ID始终存在并且是提交 PR#1 的人在提出 Pull Request 时所拥有的一系列提交的提示提交。姓名 refs/pull-requests/1/merge可能不存在，但如果确实存在，则它是 Bitbucket 已经进行的 merge 提交的哈希 ID。这是 Bitbucket 尝试的测试 merge 的结果，以查看 pull 请求是否可以按原样 merge 。

如果 merge 提交已经存在，您可以将其检索到您自己的 Git 存储库中。请注意，如果它确实存在，则意味着 Bitbucket 的 Git 能够在没有人工帮助的情况下解决 merge 问题。因此，你可以让你的 Git 做同样的事情，如果这比获得它们的 merge 更容易或更方便的话。虽然您将获得不同的 merge 提交，但它将具有相同的关联树:见下文。

为什么原来的问题有点傻

提交的散列 ID 是通过散列提交的内容来计算的。

以下是示例提交的内容(但 @ 更改为 以可能减少某人的垃圾邮件负载):

tree a830f927ccaf7164b03602729cc7078c79d5bbf2
parent fab4a8a39666793d407371f519e8b6d25d33fa84
author Junio C Hamano <gitster pobox.com> 1558252002 +0900
committer Junio C Hamano <gitster pobox.com> 1558252002 +0900

Git 2.22-rc1

Signed-off-by: Junio C Hamano <gitster pobox.com>

请注意， merge 后的树(此处的单词 tree 后面的哈希 ID)在 merge 之前是未知的，但是您可以通过 merge 找到这棵树，然后您就会知道这棵树。

以上是非 merge 提交；这是一个 merge 提交:

tree ea8851107dda1a726b3eec91d347996ead1ab683
parent 8c59ba9a764f1ae1f8d176ea17c636183cfd7267
parent f3a3a021c716b46ed35e6b7171bbff4d8042da68
author Junio C Hamano <gitster pobox.com> 1558251935 +0900
committer Junio C Hamano <gitster pobox.com> 1558251935 +0900

Merge branch 'js/difftool-no-index'

The "--dir-diff" mode of "git difftool" is not useful in "--no-index"
mode; they are now explicitly marked as mutually incompatible.

* js/difftool-no-index:
  difftool --no-index: error out on --dir-diff (and don't crash)

主要区别在于 merge 有两个父级。 merge 的父项很明显:第一个是您进行 merge 之前的当前提交，另一个是您打算 merge 的提交的哈希 ID。

后 tree和 parent行，不过，来 author和 committer线。这些不仅包含一个已知的数量——姓名和电子邮件地址——而且还包含一个不可预测的数量: merge 完成的确切秒数(例如 1558252002)。

其余的 merge 提交内容是提交消息，想必你知道了。

因此，为了预测 merge ，您需要:

执行 merge ，找到 tree

预测您稍后进行 merge 的时间

一旦知道了这两位数据，就可以填写头部内容并计算 merge 的哈希 ID。

当然，第一步——执行 merge ——现在就足够了:你有 merge ；所以就用它吧。这也是 Bitbucket 执行测试 merge 的原因——和 GitHub 一样，尽管它们的名字是 refs/pull/number/head和 refs/pull/number/merge .