当且仅当两个分支在合并之前对同一行进行了修改时，才会发生合并冲突。但是，即使没有发生合并冲突，也可能是两个完美工作的分支合并的结果不起作用。有一种方法可以预先合并两个分支，处理应该由合并产生的文件（可能还添加/删除/修改其他分支），然后提交合并结果？我已经尝试过，但是只有在发生合并冲突并且仅在涉及的代码行上才有这种可能性。我确定可以在 git 中完成（我不能是唯一遇到此问题的人），但我不知道要启动的命令序列。
【问题讨论】：
标签： git merge merge-conflict-resolution
git merge --no-commit <branchName>
专门用于此目的（请参阅doc）。
（之后您不需要做git merge --continue，只需在当前状态适合您的需要时提交您的工作。不要忘记add 任何修改，您可以在之后您的非-提交合并）
【讨论】：
git commit，提交将是合并的一个，对吧？
git merge --continue？
--continue。感谢这个好问题，我已经编辑了我的答案。
git merge --continue进行合并，如果我有合并冲突，情况是否相同？
git merge --continue 实际运行 git commit（如果要完成合并）。因此两者完全相同（如果要完成合并；如果没有，git merge --continue 会出错，因为没有正在进行的合并提交，而git commit 可能会继续提交非合并）。
（这应该是注释，但有点长，需要一些格式。）
在我写这篇文章的时候有两个答案：
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，无论您喜欢哪个）。
【讨论】：
您也可以先进行合并，然后对其进行测试，修复问题，最后 git commit --amend 在推送之前对合并提交进行修复。
【讨论】：