假设我有 2 个分支 - master 和 feature。此外，我有一个拉取请求，其中包含 2 次从功能到主控的提交。如果我合并它，我将有一个合并提交。这个提交在合并之前已经以某种方式配置了吗？我可以看看它吗？我知道我可以获得 refs/pull-requests/1/from 和 refs/pull-requests/1/merge 分支的哈希值，但是我可以得到类似“合并”提交的信息吗？
...我知道我可以得到散列
refs/pull-requests/1/from和refs/pull-requests/1/merge分支，但是我可以得到像“合并”提交之类的东西吗？
这些不是 Git 功能，而是 Bitbucket 功能。（其他一些网络服务可能使用相同的技术，但我会在这里假设 Bitbucket。）见https://community.atlassian.com/t5/Bitbucket-questions/Difference-of-refs-pull-requests-lt-ID -gt-merge-and-refs-pull/qaq-p/772142（并注意该问题答案中的注意事项）。
这两个在技术上不是分支，只是这取决于我们如何定义分支这个词。请参阅我们所说的“分支”究竟是什么意思？ 但它们是提交哈希 ID。由 给出的哈希 IDrefs/pull-requests/1/from始终存在，并且是提交 PR#1 的人在提出 Pull Request 时所拥有的一系列提交的提示提交。该名称refs/pull-requests/1/merge 可能不存在，但如果存在，则它是 Bitbucket 已经进行的合并提交的哈希 ID。这是 Bitbucket 尝试的测试合并的结果，以查看拉取请求是否可以按原样合并。
如果合并提交已经存在，您可以将其检索到您自己的 Git 存储库中。请注意，如果它确实存在，则意味着 Bitbucket 的 Git 能够在没有人工帮助的情况下解决合并问题。因此，你可以让你的Git 做同样的事情，如果这比获得它们的合并更容易或更方便的话。虽然您将获得不同的合并提交，但它将具有相同的关联树：见下文。
提交的散列 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此处单词后面的哈希 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)
主要区别在于合并有两个父级。合并的父项很明显：第一个是您进行合并之前的当前提交，另一个是您打算合并的提交的哈希 ID。
在经过tree和parent线条，不过，来的author和committer线。这些不仅包含一个已知的数量——姓名和电子邮件地址——而且还包含一个不可预测的数量：合并完成的确切时间（1558252002例如）。
其余的合并提交内容是提交消息，想必你知道了。
因此，为了预测合并，您需要：
tree一旦知道了这两位数据，就可以填写头部内容并计算合并的哈希 ID。
当然，第一步——执行合并——现在就足够了：你有合并；所以就用它吧。这也是 Bitbucket 执行测试合并的原因——GitHub 也是如此，尽管它们的名称是和。refs/pull/number/headrefs/pull/number/merge