Question

比方说，我有2个分支-主分支和功能分支。我也有一个从功能到主2次提交的拉取请求。如果我合并它，我将有一个合并提交。合并之前已经以某种方式配置了该提交？我可以以某种方式看一下吗？我知道我可以从refs / pull-requests / 1 /和refs / pull-requests / 1 / merge分支中获取哈希，但是我可以得到类似“ merge”的提交吗？

Answer 1

首先，让我们回答您不知道要问的问题

...我知道我可以获取refs/pull-requests/1/from和refs/pull-requests/1/merge分支的哈希，但是我可以得到诸如“合并”提交的信息吗？

这些不是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（并注意该问题的答案中的警告）。

从技术上讲，这两个不是分支，只是这取决于我们如何定义 branch 一词。参见What exactly do we mean by "branch"?，但它们是提交哈希ID。 refs/pull-requests/1/from给出的哈希ID始终存在，并且是进行PR＃1的任何人在发出“拉取请求”时所进行的一系列提交的最重要的提交。名称refs/pull-requests/1/merge 可能不存在，但如果确实存在，则为Bitbucket已进行的合并提交的哈希ID。这是Bitbucket尝试进行测试合并的结果，以查看是否可以按原样合并合并请求。

如果合并提交已经存在，则可以将其检索到自己的Git存储库中。请注意，如果确实存在，则意味着Bitbucket的Git无需人工帮助即可解决合并问题。因此，如果您的 Git比获得他们的合并更容易或更方便，则可以执行相同的操作。虽然您将获得不同的合并 commit ，但它将具有相同的关联 tree：见下文。

为什么原来的问题有点愚蠢

提交的哈希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>

请注意，直到进行合并后，合并的 tree （此处单词tree之后的哈希ID）才是未知的，但是您可以进行合并以找到树和然后您就会知道那棵树。

以上是非合并提交；这是一个合并提交：

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)

关键区别在于合并有两个父对象。合并的 parents 很明显：第一个是合并之前的当前提交，另一个是要合并的提交的哈希ID。

在tree和parent行之后，出现author和committer行。这些不仅包含已知数量（名称和电子邮件地址），而且还包含不可预测的数量：完成合并的确切秒数（例如1558252002）。

其余的合并提交内容都是提交消息，大概是您知道的。

因此，为了预测合并，您需要：

执行合并，找到tree
预测以后要进行合并的时间

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

当然，第一步-执行合并-现在就足够了：您拥有合并；所以就用吧这也是Bitbucket进行测试合并的原因-GitHub也是如此，尽管其名称分别为refs/pull/number/head和refs/pull/number/merge。

是否可以在合并之前获取合并提交的哈希值？

1 个答案:

首先，让我们回答您不知道要问的问题

为什么原来的问题有点愚蠢