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

Question

这个问题基本上是相同的： How to test a merge without actually merging first

但是，上面的问题并没有规定必须由人类以外的任何事物来完成。就我而言，它必须是自动/编程的。

我想测试一下是否可以将一个分支合并到另一个分支中。举例来说，我想测试发布分支是否可以合并到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才会启动您的首选编辑器 ¹ ：

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

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

GIT_EDITOR=true git merge --quiet $hash

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

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

---

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

• $GIT_EDITOR在环境中
通过core.editor配置的
• git config
• 内置的默认编辑器

使用git var GIT_EDITOR会告诉您您选择的或默认的编辑器。

Answer 2

晚了聚会，但是你可以这样

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