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 忽略空格数量变化、制表符/空格转换、行首/行尾空格。它不影响功能逻辑，只绕过格式类冲突。

GitHub Actions Retry Recovery Audit

审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。

下载

• 适用场景：团队混用编辑器、CI 自动格式化、跨平台开发
• 命令示例：git merge -Xignore-space-change feature-branch
• 注意：该参数仅作用于本次合并，不改变仓库配置；也不能解决换行符（\r\n vs \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 是防御层，手动清理是兜底手段，但不该成为日常流程。