Git中如何自动解决易判定的简单合并冲突

本地对应位置的代码片段：

disableCaching()
setupGoogleMaps()

远程分支对应位置的代码片段：

disableCaching()
FirebaseApp.configure()
initializeNotificationService()
setupGoogleMaps()

从开发的逻辑判断，远程只是在setupGoogleMaps()上方加了两行代码，合并不应该有阻碍，但Git报冲突的核心原因非常直接：
Git是纯文本行级比对工具，完全不理解代码语义，自动合并的判定规则非常机械，它不会像人一样通读代码判断逻辑兼容性，只认文本行的改动范围。

Git做三方合并的时候，会先找两个分支分叉点的「共同祖先版本」作为基准，分别计算本地分支、远程分支相对于基准的改动：

• 如果两个分支改动的行区间完全不重叠，且改动点周围有足够多未修改的代码行作为定位锚点，Git会自动把两处改动拼合
• 只要两个分支的改动落在Git判定的同一段相邻代码区间内，不管人看起来逻辑多通顺，Git都会直接抛出冲突，交给人工判断最终保留内容。

对应这个复现场景，本地feature分支相对于共同祖先，是把disableCaching()和setupGoogleMaps()之间的原有代码全部删除，只留了空行；而远程master分支在完全相同的位置，新增了Firebase和通知服务的两行初始化代码。两个分支都修改了两个函数调用之间的同一段区域，Git无法判定最终是要保留本地的空行状态、还是要远程新增的两行代码、还是要做其他组合，因此触发手动合并提示。

IDE里的一键自动修复按钮失效也是同样原因：这类按钮本质只能处理Git因为换行符、缩进、行尾符这类格式问题导致的误判冲突，没法处理两个分支实打实修改了同一代码区间的场景。

默认的Git合并逻辑和IDE自带的简易合并工具没法自动处理这类冲突，但可以通过调整配置、换用更专业的工具减少这类手动合并成本：

• 调整Git默认diff/合并算法：把默认的myers算法换成patience算法，同时开启diff3冲突样式，能让Git对代码块的定位更精准，减少一部分无意义冲突，对应配置命令：

  git config --global merge.conflictstyle diff3
  git config --global diff.algorithm patience
  

• 用语义合并工具替代默认文本合并：比如针对iOS开发的Swift/Objective-C语言，可以用语义感知的合并工具，这类工具会先解析代码的语法树，能识别出「在函数调用前新增代码」和「删除同位置旧代码」是不冲突的改动，自动完成合并。
• 针对团队高频出现的固定冲突模式，可以给指定类型的文件编写自定义Git合并驱动，按照团队约定的规则自动合并，但通用场景下投入产出比不高。

该问题可以通过以下步骤稳定复现：

1. 执行命令git checkout featurebranch切换到特性分支
2. 执行命令git pull origin master拉取远程主分支代码触发合并，即可看到对应冲突提示。

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