core.autocrlf不支持按分支设置，其作用范围为全局或仓库级；所谓“某分支生效”实为.gitattributes文件在该分支中存在并被git自动应用所致，因.gitattributes优先级高于core.autocrlf，可按路径精确控制换行符行为。

为什么 core.autocrlf 在特定分支上不起作用

Git 的换行符配置是全局或仓库级的，core.autocrlf 本身不支持“按分支设置”。你看到的“某分支生效”现象，通常是工作区文件状态、检出历史或 .gitattributes 文件介入导致的错觉。真正能按路径（包括分支所含文件）控制 CRLF 行为的，只有 .gitattributes —— 它在检出和提交时由 Git 自动读取并应用。

用 .gitattributes 精确控制某分支的换行符行为

假设你想让 dev 分支下的所有 .py 文件禁用 CRLF 转换（即始终以 LF 存储和检出），关键不是改分支配置，而是确保该分支中存在并正确应用 .gitattributes：

• 在 dev 分支根目录下创建或编辑 .gitattributes
• 写入：

  * text=auto eol=lf

  （对所有文本文件统一用 LF）
• 或更精准：

  *.py text eol=lf

  （只约束 Python 文件）
• 必须用 git add .gitattributes 提交，否则其他分支检出时不会生效
• 已检出的文件需重新刷新：运行 git rm --cached -r . && git reset --hard（⚠️会丢弃工作区未提交更改）

core.autocrlf 和 .gitattributes 冲突时谁赢

当两者同时存在，.gitattributes 优先级更高。例如：

One-click installation of GitHub projects

GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。

下载

• 本地设了 git config core.autocrlf true（Windows 默认）
• 但项目根目录有 .gitattributes 含 *.sh eol=lf
• 那么所有 .sh 文件都会忽略 core.autocrlf，强制以 LF 检出
• 没被 .gitattributes 明确匹配的文件，才退回到 core.autocrlf 规则

所以“强制关闭 CRLF”本质是：删掉或覆盖 core.autocrlf 的影响，靠 .gitattributes 做最终裁定。

容易被忽略的三个硬性前提

即使写了正确的 .gitattributes，以下任一条件不满足，CRLF 还是会偷偷出现：

• .gitattributes 文件本身必须用 LF 换行（用 Notepad++ 或 VS Code 确认编码为 UTF-8 + LF，否则 Git 解析失败）
• 文件必须是 Git 跟踪状态（git status 显示为 modified 或 up to date，而非 untracked）
• 修改后重新检出前，要清空 Git 缓存：仅改 .gitattributes 不够，得 git add -u && git commit，再 git checkout 切回该分支触发重应用

分支切换本身不会自动重写工作区换行符；只有 Git 重新检出文件时，才会依据当前分支里的 .gitattributes 执行转换。