Git换行符冲突本质是CRLF/LF被误判为内容变更，非真实代码冲突；应通过.gitattributes统一规则、git add --renormalize .清理暂存状态，并配合编辑器与CI管控源头。
这类冲突不是代码逻辑冲突，而是 Git 对换行符的“感知冲突”——文件内容没变，但 Git 认为 CRLF 和 LF 的差异是实质性修改。真正要处理的，是统一规则和清理残留状态，而不是像解决普通 merge 冲突那样手动选行。
先确认问题本质：这不是真正的合并冲突
当你看到 warning: CRLF will be replaced by LF 或 git status 显示已修改但 diff 为空，说明 Git 在暂存区记录的是 LF，而工作区文件实际保存为 CRLF（或反之）。这通常发生在：
- 团队成员 core.autocrlf 配置不一致（比如有人设 true，有人设 input 或 false）
- .gitattributes 已提交但未生效（比如文件名错写成 .gitattributes.txt，或没 git add 提交）
- 编辑器（如记事本、旧版 Sublime）自动把 LF 文件另存为 CRLF，而 Git 还按旧规则追踪
立即止血：用 renormalize 强制重走换行流程
不用删文件、不用重 clone，一条命令即可让 Git 按当前 .gitattributes 和 core.autocrlf 重新评估所有文件：
git add --renormalize .
执行后会刷新暂存区，消除“假修改”。如果提示大量文件被重写，说明规则已起效；若仍报错，说明 .gitattributes 未被识别或配置冲突。
根治方案：项目级规则必须靠 .gitattributes
全局 core.autocrlf 不可靠，唯一能强制跨平台一致的方式是把策略写进项目本身：
- 在仓库根目录新建纯文本文件：.gitattributes（注意开头是点，无扩展名）
- 写入明确规则，例如：
# 默认：自动识别文本文件，统一转为 LF * text=auto eol=lf <h1>脚本类必须 LF（Linux/macOS 才能执行）</h1><p><em>.sh text eol=lf </em>.py text eol=lf *.yml text eol=lf</p><h1>Windows 批处理保留 CRLF</h1><p>*.bat text eol=crlf</p><h1>二进制文件禁止任何换行处理</h1><p><em>.png binary </em>.zip binary *.pdf binary
- 执行：
git add .gitattributes && git commit -m "chore: enforce line endings via .gitattributes"
同步团队环境：三步清零旧状态
即使加了 .gitattributes，旧的暂存状态可能卡住。需彻底刷新本地工作区：
- 关闭所有编辑器（防止文件被锁）
- 运行：
git rm --cached -r . git reset --hard git add --renormalize .
- 检查结果：
git status应该干净；打开任意 .py 或 .sh 文件，确认 VS Code 等编辑器右下角显示为 LF
预防再发生：编辑器与 CI 双保险
光靠 Git 不够，得从源头堵住 CRLF 流入：
-
VS Code：在工作区 settings.json 加：
"files.eol": "\n" -
CI 流水线（如 GitHub Actions）：加一步检查脚本，拒绝含 CRLF 的文本文件 PR：
git grep -I $'\r' -- '*.py' '*.js' '*.sh' > /dev/null && { echo "CRLF detected!"; exit 1; } || echo "OK" - 提醒新成员：首次拉取后运行一次
git add --renormalize .
