Git默认不忽略空格或换行符差异，三方合并将格式改动视为内容变更而报冲突；需用-Xignore-space-change等参数显式跳过，或通过.gitattributes统一规范换行与文本处理策略。
Git 默认不会忽略空格或换行符差异，所谓“自动忽略格式修改”是误解——它只在特定策略和参数下才跳过这类冲突。
为什么 git merge 仍报 whitespace 冲突
Git 的三方合并算法基于文本行内容比对，只要两分支对同一行做了任何改动（哪怕只是把 \n 换成 \r\n 或删了末尾空格），且无共同祖先变更记录，就会标记为冲突。你看到的 CONFLICT (content) 不是因为 Git “太敏感”，而是它确实无法判断哪边的格式更合理。
- 换行符差异（Unix vs DOS）会被视为整行重写，触发冲突
- 缩进空格增减、行尾空格、tab/spaces 混用，同样算“内容变更”
-
git merge默认使用recursive策略，不启用任何 whitespace 忽略逻辑
用 -Xignore-space-change 参数跳过常见格式差异
这是最直接有效的办法：在合并时显式告诉 Git 忽略空格数量变化、制表符/空格转换、行首/行尾空格。它不影响功能逻辑，只绕过格式类冲突。
- 适用场景：团队混用编辑器、CI 自动格式化、跨平台开发
- 命令示例：
git merge -Xignore-space-change feature-branch - 注意：该参数仅作用于本次合并，不改变仓库配置；也不能解决换行符（
\r\nvs\n）冲突 - 若需同时忽略换行符，得额外加
-Xignore-all-space（慎用，可能掩盖真实内容差异）
.gitattributes 文件统一换行与空格策略
靠每次加参数治标不治本。真正防冲突，得从源头约束格式行为。在项目根目录建 .gitattributes，声明文件类型处理规则：
* text=auto eol=lf *.py text eol=lf *.md text eol=lf *.bat text eol=crlf
-
eol=lf强制所有平台检出 Unix 换行符，避免unix2dos类操作引入污染 -
text=auto让 Git 自动识别文本文件并做换行符标准化 - 该文件本身必须用 LF 提交，否则 Git 无法正确解析其规则
- 已有历史中的 DOS 换行文件，需先统一转换再提交，否则旧 commit 仍会引发冲突
为什么不用 --no-commit + 手动清理再提交
有人想用 git merge --no-commit 合并后手动删冲突标记、再格式化全文件。这看似可控，实则危险：
- 删除冲突标记的同时，可能误删一方的功能性修改（尤其当格式改动和逻辑改动在同一块）
- 全文件重新格式化会污染
git blame，让后续查 bug 失去上下文 - 如果团队多人同时这么做，下次合并又会因“格式不一致”再次冲突
- Git 无法区分“我改了业务逻辑”和“我只调了缩进”，导致 diff 失真
真正的边界在于：格式规范必须前置约定，而非事后补救。工具参数和 .gitattributes 是防御层，手动清理是兜底手段，但不该成为日常流程。
