Git合并策略、驱动与工具的定义准确性及信息补全问询

一、合并策略 #

你的理解大部分准确，仅存在一处关键偏差：

• 合并策略是全局层面处理整个合并流程的逻辑，并非针对每个待合并文件单独调用。它负责统筹：分支拓扑分析、重命名检测、决定哪些文件需要进入内容合并阶段，以及选择/调度底层合并驱动的执行。
• 当{parent1, parent2, base}三者中有两者相同时，确实会跳过底层合并驱动（如git merge-file），因为这种场景下可直接沿用相同版本的文件内容，无需内容合并。
• 自定义合并策略的机制正确：系统中存在git-merge-xyz可执行文件时，git merge --strategy xyz会调用它；Git自带的策略（如recursive、octopus）都是Git主程序的链接。
• 多策略指定的逻辑正确：Git会优先选用第一个执行成功（退出码0）的策略，若多个策略退出码为1（表示存在冲突），则会启发式选择最优结果。
• 调试自定义策略时，用GIT_TRACE=1 git merge -s <strategy>查看参数、关注环境变量影响的方法正确。

二、合并驱动 #

你的理解核心逻辑正确，但存在一处概念混淆，同时需补充关键信息：

• 触发条件准确：仅当合并策略判定文件需要内容合并，且{base, parent1, parent2}三者内容均不同时，才会自动调用合并驱动。若三者中有两者相同，确实不会触发驱动。
• 执行细节正确：每个冲突文件仅调用一次，运行于临时文件环境，可通过%P获取原文件路径，读取%O（base版本）、%A（当前分支版本）、%B（另一分支版本）的内容后，将合并结果（含冲突标记或已解决内容）写入%A文件。
• 关键修正：通过Git属性指定的是合并驱动，而非合并策略。例如*.json merge=json-driver是为匹配模式的文件指定自定义合并驱动，而非策略。
• 补充：Git内置多种合并驱动，如默认的merge（调用git merge-file）、ours（直接保留当前分支内容）、theirs（直接采用另一分支内容）、union（简单合并所有新增行）等。

三、合并工具（mergetool） #

你的理解完全准确，补充两点细节：

• 合并工具是交互式冲突解决工具，仅在用户手动执行git mergetool时启动，逐个处理带有冲突标记的文件，支持可视化编辑冲突内容。
• 部分合并工具可配置自动解决简单冲突，但核心仍是用户触发的交互式流程，且仅处理Git标记为冲突的文件，不会主动检查“无冲突但逻辑错误”的合并结果。

额外补充 #

合并策略、驱动、工具的层级关系：合并策略是顶层调度者，决定是否需要调用合并驱动处理文件内容；合并驱动自动处理内容合并，若产生冲突则标记文件；合并工具是用户手动触发的冲突解决入口，处理已标记的冲突文件。

内容的提问来源于stack exchange，提问作者mernst