git merge -x参数共4种：ignore-space-at-eol忽略行尾空格，ignore-space-change忽略行内空白数量变化但要求非空白内容一致，ignore-all-space最激进、仅非空白字符相同即忽略所有空白差异，ignore-cr-at-eol专治dos/unix换行符混用。
Git 默认对空格、换行符、制表符等空白字符极其敏感，哪怕只是 hello world 变成 hello world （末尾多一个空格），或 Unix 换行 \n 变成 DOS 换行 \r\n，都可能触发冲突。这不是 bug，而是 Git 的设计哲学：宁可报冲突，也不擅自丢弃差异。但实际协作中，这类“纯空白冲突”往往毫无业务意义，徒增解决成本。
git merge -X 参数怎么选？看空白变化类型
Git 提供了 4 种内置的空白忽略策略，通过 -X（注意是大写 X）传给 git merge，它们作用范围不同，不能混用：
-
ignore-space-at-eol：只忽略**行尾空格增减**。比如你分支每行多了 2 个空格，而主干没加，合并时不报冲突，最终保留主干那行（不带尾空格）。 -
ignore-space-change：忽略**行内空白数量变化**，但要求非空白内容完全一致。例如puts'hello'和puts 'hello'（中间空格数不同）会被视为相同；但puts'hello'和puts'world'仍会冲突。 -
ignore-all-space：最激进——只要非空白字符序列相同，就忽略所有空白差异。哪怕一行全是空格、另一行完全没空格，只要其余字符一样，就直接接受。 -
ignore-cr-at-eol：专治 DOS/Unix 换行符混用。当一方是\r\n、另一方是\n时，不视为差异。
注意：-X 只在本次合并生效，不会改变仓库配置。如果想长期生效，需配 git config --global merge.ff false + 自定义合并驱动（较重，一般不推荐）。
为什么 git merge -Xignore-space-change 还是冲突？
常见误判点：你以为只是空格问题，其实还有别的差异。Git 的空白忽略策略是“先比非空白内容，再按规则处理空白”，一旦非空白部分不同，空白策略就失效。典型场景包括：
- 某行在两个分支中**文字不同**（如
'hello world'vs'hello mundo'），哪怕只差一个字母，ignore-all-space也救不了它； - 某行在两个分支中**缩进方式不同**（空格 vs 制表符），而
ignore-space-change不认为\t（制表符）等价； - 你用了
ignore-space-at-eol，但冲突行其实是**中间有空格增删**，而非仅末尾——它对此无能为力。
验证方法：执行 git diff --no-index --ignore-space-change <file1><file2></file2></file1>，看是否真无差异。如果命令输出为空，说明空白策略理论上应生效；若有输出，则说明存在非空白差异。
merge.tool 图形化工具里空白怎么处理？
git mergetool 本身不自动应用 -X 策略，它展示的是 Git 已计算出的冲突块（即 Git 认为需要人工介入的部分）。也就是说，如果你没加 -X 参数，图形工具看到的就是原始冲突；加了 -X 后，Git 已提前消除了部分冲突，mergetool 启动时可能根本没文件要处理。
部分工具（如 meld、vimdiff）支持自身设置忽略空白，但这属于工具层行为，不影响 Git 的索引状态和后续提交。真正起效的，永远是 Git 合并时用的 -X 参数或 .gitattributes 中的 whitespace 设置。
临时启用图形工具：运行 git mergetool -t meld（需提前安装 meld），它会依次打开每个未解决冲突的文件，左侧是当前分支（LOCAL），右侧是待合并分支（REMOTE），中间是合并结果（MERGED）。
真正要小心的不是参数，是换行符和编码
Windows/macOS/Linux 的默认换行符不同，ignore-cr-at-eol 能解决 \r\n vs \n，但无法处理 \r（旧 Mac）或混合换行。更隐蔽的问题是文件编码：UTF-8 with BOM 和 UTF-8 no BOM 在 Git 看来是二进制差异，-X 完全无效。这类问题常表现为“明明没改内容，却整文件标红”。
预防比补救重要：团队统一配置 .gitattributes，例如写入 * text=auto eol=lf，让 Git 自动标准化换行符；编辑器设为 UTF-8 no BOM；CI 流水线加检查脚本验证空白一致性。
