.gitattributes 的 text=auto 在特定分支不生效，是因为该文件仅对当前检出分支中已存在的提交生效；若 feature/x 分支未包含该配置提交，则回退至全局 core.autocrlf 设置。

为什么 .gitattributes 的 text=auto 在特定分支上不生效

Git 的行尾换行符（CRLF vs LF）自动转换由 .gitattributes 控制，但这个文件本身受 Git 版本控制——它只对「当前检出分支中存在该文件」的提交生效。如果你在 main 分支里配置了 * text=auto eol=lf，而切换到 feature/x 分支时该分支尚未合并该 .gitattributes 提交，那么 Git 就会回退到全局或系统默认行为（通常是 core.autocrlf=true），导致 CRLF 被悄悄提交。

所以不是“分支级启用”，而是“分支是否携带生效的 .gitattributes 文件”。要让某分支强制使用 LF，必须确保该分支的根目录下存在且已提交了正确的 .gitattributes。

• .gitattributes 必须位于仓库根目录（或子目录，但作用域仅限于其所在路径及子路径）
• 文件内容需显式声明 eol=lf，仅 text=auto 不够稳定（尤其 Windows 上易被 core.autocrlf 覆盖）
• 修改后必须 git add .gitattributes && git commit -m "enforce lf"，否则不会影响后续检出

如何为一个分支单独设置 LF 强制换行（不污染其他分支）

典型场景：你正在维护一个需要严格 LF 的 CI 构建分支（比如 deploy/staging），但开发分支仍允许宽松处理。这时不能靠全局配置，而要让该分支自带约束能力。

最可靠做法是：在目标分支上创建并提交专属 .gitattributes，并确保它覆盖全部关键文件类型：

* text=auto eol=lf
*.py text eol=lf
*.js text eol=lf
*.json text eol=lf
*.md text eol=lf
*.sh text eol=lf
*.yml text eol=lf
*.yaml text eol=lf

注意：text 属性比 text=auto 更强硬——它强制 Git 将这些文件视为文本，并忽略 core.autocrlf 设置；eol=lf 则覆盖所有平台的 checkout 行为。

Git

程序猿必备版本控制工具

下载

• 如果该分支是从旧提交分出来的，记得先 git checkout deploy/staging && git merge main（或 cherry-pick）把 .gitattributes 拉进来
• 已有 CRLF 文件已提交？运行 git rm --cached -r . && git reset --hard 可触发重索引（慎用，建议先备份）
• CI 环境中若仍出现 CRLF，检查是否设置了 core.autocrlf=false —— 这会禁用所有 eol 规则

git config core.eol 和 core.autocrlf 的优先级关系

本地 Git 配置和 .gitattributes 会冲突。实际生效顺序是：.gitattributes > core.eol > core.autocrlf。但前提是 .gitattributes 存在且匹配文件。

常见误操作：开发者在本地设了 git config --global core.autocrlf true，结果即使分支有 .gitattributes，Windows 用户 checkout 后仍是 CRLF——因为 core.autocrlf 会覆盖 eol=lf 对二进制以外文件的处理逻辑。

• 验证当前生效规则：运行 git check-attr -a <filename></filename>（例如 git check-attr -a package.json），看输出中 eol 是否为 lf
• 临时绕过本地干扰：CI 脚本中加 git config core.autocrlf false，确保 .gitattributes 完全主导
• core.eol 是低优先级兜底项，仅当无 .gitattributes 时才起作用，不推荐依赖它做分支级控制

已提交的 CRLF 文件如何批量修正而不炸掉历史

如果目标分支里已有大量 CRLF 提交，直接 git add --renormalize . 会触发全部文件重写，导致 diff 巨大、PR 失去可读性。稳妥做法是分阶段清理：

• 先确认范围：git ls-files --eol | grep 'crlf' 查看哪些文件还带 CRLF
• 对新增/修改文件自动修正：设置 git config core.autocrlf input（Linux/macOS）或 git config core.autocrlf false（Windows），再配合 .gitattributes 中的 eol=lf
• 对存量文件，用 git add --renormalize <path></path> 逐个目录推进，比如先 git add --renormalize src/，再 git add --renormalize tests/
• 提交时加 -m "chore: normalize line endings in src/ (LF only)"，避免与功能变更混在一起

真正麻烦的不是配置，而是团队协作中有人漏掉 .gitattributes 提交，或者用 GUI 工具绕过命令行直接 commit —— 这类行为会让行尾问题反复出现，得靠 CI 阶段加校验脚本卡住，比如 grep -rl $'\r$' . || true 返回非空就 fail。