Git不支持全局自动解决冲突，pull.rebase=true仅改变整合方式（重放提交而非创建合并提交），遇冲突仍需人工解决并执行git add和rebase --continue；merge.conflictStyle只调整冲突标记格式，不能跳过判断。
Git 不支持全局设置“默认自动合并策略”来跳过冲突确认。所谓“默认策略”，其实是你执行 git pull 或 git merge 时，Git 根据当前配置决定用 merge 还是 rebase，而不是让它替你决定哪行代码该保留——后者永远需要人工介入。
为什么 git config --global pull.rebase true 不等于“自动解决冲突”
这个配置只影响 git pull 的底层行为：它会让 Git 先把本地提交“重放”到远程最新提交之后（即执行 rebase），而不是创建一个合并提交（merge）。但它不会绕过冲突；一旦 rebase 过程中遇到无法自动应用的提交，Git 一样会停在冲突处，等你手动解决、git add、再 git rebase --continue。
- 如果你设了
pull.rebase = true，但没配branch.autoSetupRebase，新分支仍可能默认走 merge -
rebase本质是线性化历史，不是合并逻辑简化；它甚至可能让冲突更频繁（比如多个本地提交都碰到了同一段被远程改过的代码） - 误以为开了这个就“不用管冲突”，反而容易在
rebase --continue时糊里糊涂跳过关键修改
merge.conflictStyle 能改变冲突标记格式，但不能跳过判断
这个配置影响的是冲突块的呈现方式，不改变 Git 是否抛冲突。常用值有：
-
merge（默认）：显示<<<<<< HEAD/=======/>>>>>> branch-name -
diff3：多加一行，显示共同祖先版本内容，方便对照 —— 配置命令是git config --global merge.conflictStyle diff3
启用 diff3 后，冲突块会变成三段：
<<<<<<< HEAD 本地修改 ||||||| merged common ancestors 共同祖先里的原始内容 ======= 远程分支修改 >>>>>> origin/main
这对理解“两边各自改了什么、原始是什么样”很有帮助，尤其适合重构类冲突，但依然要你动手删标记、留逻辑。
真正能减少手动干预的配置，只有工具链层面
Git 本身不会替你做业务决策，但你可以用配置把人肉操作压缩到最少：
- 指定图形化合并工具：
git config --global merge.tool kdiff3（或vscode、beyondcompare），再配git config --global mergetool.kdiff3.trustExitCode true，这样git mergetool启动后保存退出即自动标记为已解决 - 让
git status更清晰：加git config --global status.showUntrackedFiles no（避免干扰），或用git config --global alias.st 'status -s'快速扫冲突文件 - 预防性配置：在团队内统一
core.autocrlf和core.whitespace，避免因换行符或空格差异触发假冲突
这些配置不消除冲突，但能把从“发现冲突 → 打开文件 → 找标记 → 删/选/改 → 保存 → git add → git commit”这一串动作，压到两步：运行 git mergetool，关掉工具窗口。
最常被忽略的一点是：很多人配完 merge.tool 却没验证是否生效，结果 git mergetool 还是弹出 Vim。验证方法很简单：git mergetool --tool-help 看列表里有没有你配的工具名，再试一次 git mergetool —— 如果没反应，大概率是路径没加进 $PATH，或者工具本身没安装。
