这个问题基本上是相同的: 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
打开,我们必须做点什么(不确定什么)。有没有办法将其关闭?
答案 0 :(得分:1)
只有在满足以下所有条件的情况下,运行git merge
才会启动您的首选编辑器 1 :
git merge
的参数都已成功解析)。--allow-unrelated-histories
。--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
脚本这样做。请小心此技巧,因为它会绕过许多常规的安全检查。
1 您的首选编辑器由以下各种设置之一定义:
$GIT_EDITOR
在环境中core.editor
配置的git config
使用git var GIT_EDITOR
会告诉您您选择的或默认的编辑器。
答案 1 :(得分:0)
晚了聚会,但是你可以这样
git merge-tree $(git merge-base feature_branch master) feature_branch master