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 执行转换。
