Git merge将换行符、缩进标为冲突，是因为默认按逐行文本差异比对；跨平台换行符（\n/\r\n）或缩进不一致（2/4空格）导致Git判定每行都不同，从而触发大量格式化冲突。
为什么git merge会把换行符、缩进全标成冲突
不是代码逻辑真有矛盾，而是 Git 默认按「逐行文本差异」比对。当你和同事一个用 Unix 换行（\n），一个用 Windows 换行（\r\n），或一个用 2 空格缩进、一个用 4 空格，Git 就认为「每一行都不同」——于是整个文件被标为 both modified，冲突块密密麻麻。
git merge时跳过空白差异的实操命令
核心是告诉 Git：别管空格、换行、tab 的变化，只看实质内容差异。用 -Xignore-space-change 或更激进的 -Xignore-all-space 参数：
-
git merge -Xignore-space-change feature-branch：忽略空格数量变化（比如if→if） -
git merge -Xignore-all-space feature-branch：连空格位置、换行符类型都忽略（适合混用\n/\r\n的项目） -
git merge -Xignore-space-at-eol feature-branch：只忽略行尾空格，保留行首缩进差异（较保守）
注意：-X 是 merge 的「策略选项」，必须紧跟 git merge 命令，不能写成 git merge --strategy-option=...（旧版本不支持）。
长期避免格式化冲突的配置项
每次 merge 都加参数太累，直接设成默认行为：
- 全局生效（推荐）：
git config --global merge.ff false+git config --global merge.strategy recursive+git config --global merge.recursive.ignore-space-change true - 仅当前仓库：
git config merge.recursive.ignore-space-change true - 配合
.gitattributes文件统一换行规范：* text=auto eol=lf强制所有平台用\n
⚠️ 注意：ignore-space-change 对已存在的冲突无效——它只影响「下一次 merge」的比较逻辑。如果当前正卡在冲突里，先 git merge --abort，再用带 -X 的命令重试。
VS Code 里点几下就能跳过格式冲突
编辑器能识别 Git 的 ignore 策略，但需手动触发：
- 打开冲突文件后，右下角状态栏会出现「Accept Current Change」「Accept Incoming Change」等按钮
- 点击「Accept Current Change」或「Accept Incoming Change」时，VS Code 实际调用的是
git checkout --ours或git checkout --theirs，**不会自动过滤空白差异** - 真正起效的是：在 VS Code 设置里搜
git.mergeOptions，填入["--no-commit", "-Xignore-all-space"]，下次 merge 才会生效
最常被忽略的一点：这些策略只作用于「内容冲突」，对「文件删除 vs 修改」「重命名 vs 编辑」这类结构冲突完全无效——那种情况得靠 git status 看清楚 deleted by us / modified by them 再决定用 git rm 还是 git add。
