Question

仅当两个分支在合并之前对同一行进行了修改时，才会发生合并冲突。但是，即使没有发生合并冲突，也可能是两个完全正常工作的分支合并的结果不起作用。有一种方法可以预合并两个分支，对应该由合并产生的文件进行处理（也许还添加/删除/修改其他分支），然后提交合并结果？我已经尝试过，但是只有在发生合并冲突并且仅在涉及的代码行上才有这种可能性。我确信可以在git中完成（我不是唯一一个有此问题的人），但我不知道要启动的命令顺序。

Answer 1

git merge --no-commit <branchName>

就是为此目的而设计的（请参见doc）。

（此后您无需执行git merge --continue，只需在当前状态适合您的需要时提交您的工作即可。不要忘记add，您可以在此之后引入您的非提交合并）

Answer 2

（这应该是注释，但有点长，需要一些格式。）

在撰写本文时，有两个答案：

git merge --no-commit，调整结果（并根据需要调整git add），然后使用git commit或git merge --continue进行提交；或
git merge，进行测试和修复（并根据需要进行git add），并使用git commit --amend来避免旧的合并提交，将其替换为新的和改进的一个。

两个都可以。但是请注意，有一种流派认为您永远都不要执行任何一种操作，因为将来不可能使用自动化系统重复合并。对我来说，尚不清楚该规则的订阅者是哪种选择，因为有两种选择：

在合并之前，进行一个（或多个）提交以准备一切，以便自动合并成功并产生有效结果。
或者，在自动合并成功但产生无效结果之后，进行后续提交以解决该问题。

在任何一种情况下，任何“准备”或“修复”提交，以及任何不能单独发挥作用的提交，都应该有一条解释性的日志消息。如果是合并本身不起作用，请注意在合并提交的日志消息中：用类似以下内容的无意义的merge branch <name>消息替换：

automatic but broken merge of branch <name>

This merge has the contents that Git produces on its own,
and exists so that someone who is repeating the work in the
future can do it automatically as well, and compare.  The
*next* commit contains the manual change that makes the
merge functional, so when bisecting, use the *next* commit,
not this one.

当然，如果您更喜欢说“不要故意做出破损的承诺”的思想流派，那么您只会合并并修复（与--no-commit或--amend您更喜欢）。

Answer 3

您还可以先进行合并，然后对其进行测试，解决问题，最后git commit --amend对合并提交的修正在推送之前进行。

git merge：即使没有合并冲突，也有一种方法可以对所涉及的文件进行操作？

3 个答案: