以编程方式检查 Git 分支是否可以合并的正确方法是什么？

Question

我想测试一下一个分支是否可以合并到另一个分支中。例如，假设我想测试一个发布分支是否可以合并到 master 中，而不需要实际合并到 master 中。我想我会做这样的事情：

#!/usr/env/bin bash
git checkout master
git checkout -b master_temp
git merge my_release_branch

所以我认为如果退出代码为0，则合并成功，否则合并失败。

不过，这是我最关心的问题：假设合并成功，但它打开了交互部分。我怎样才能避免这种互动呢？有时在合并nano或vim打开期间，我们必须做一些事情（不确定做什么）。有办法把它关掉吗？

这个问题基本上是一样的，但是，这个问题并没有规定这需要由人类以外的任何人来完成。就我而言，它需要是自动/程序化的。

Answer 1

聚会迟到了，但你可以这样做

git merge-tree $(git merge-base feature_branch master) feature_branch master

Answer 2

当且仅当满足以下所有条件时，运行git merge才会启动您的首选编辑器^{1 ：}

合并成功启动（即索引没有处于错误状态，并且参数都已git merge成功解析）。
Git 找到或创建了一个合并基础。旧版本的 Git 将使用空树作为不相关历史记录的合并基础；较新的需要--allow-unrelated-histories.
由此找到的合并基础不是当前（HEAD）提交，或者您使用了--no-ff.
您传递到的另一个提交git merge还不是当前提交的祖先。（对于章鱼合并，规则稍微复杂一些，但区别应该足够清楚：有多个“其他提交”。）
-X ours合并成功且没有冲突，或者所有冲突都是通过扩展策略选项（或）解决的低级冲突-X theirs。（请注意，该-s ours策略永远不会发生冲突，从而使该约束在那里变得空洞。）
您没有传递-m并合并消息参数（或者您做了但--edit也添加了；请参阅此答案下面的评论）。
您没有指定--no-commit（由于正在进行合并提交而调用编辑器！）。

因此，您可以通过传递合并消息来保证 Git 不会运行您首选的编辑器-m。或者，您可以故意不传递合并消息，但提供GIT_EDITOR调用实际编辑器以外的其他内容的环境设置。例如：

GIT_EDITOR=true git merge --quiet $hash

将在不打开编辑器的情况下运行合并直至完成，或者由于合并本身因冲突而停止或从未开始而失败。并且，正如 Daniel H 在下面的评论中指出的那样，--no-commit抑制了最终提交，从而抑制了编辑器。

除了这些技术之外，还可以git merge-recursive直接调用。脚本git stash就是这样做的。请小心使用此技巧，因为它会绕过许多常见的安全检查。

¹您的首选编辑器由以下各种设置中的第一个定义：

使用git var GIT_EDITOR将告诉您选择或默认使用哪个编辑器。