彻底解决Git LF/CRLF警告：一条命令永久修复
直接运行以下命令即可解决问题：
git config --global core.safecrlf=false我知道你急着提交代码，但先执行这一行，再去 commit 就不会报错了。
如果仍遇到错误，将命令中的 safecrlf=false 替换为 autocrlf=true，再次运行。
全文完
若你还有疑惑，请继续阅读后续详解。
为什么会触发这个错误？
可以确信你正在使用 Windows——这是 Windows 环境下的专属问题。切换到 macOS 即可彻底规避。
为什么同事也用 Windows 却一切正常？
因为某次无意的操作将 Git 的 safecrlf 配置修改为了 true。可能是某个工具“主动”帮你修改，也可能是你曾看到某篇教程推荐 safecrlf=true 并照做了。而 Git 的默认值本就是 false，开头的命令仅仅将其恢复为默认。
想彻底理解背后的原理？请坐稳，我们开始深入分析。
什么是 LF 和 CRLF？
操作系统分为两大阵营：Windows 为一类，Unix（macOS + Linux）为另一类。两类系统在表示空格等不可见字符时方式一致，但在表示“换行”时采用不同的字符序列：Windows 使用 CRLF，Unix 使用 LF。
问题在于：如何保证代码/文本在所有系统上正常显示与运行？Git 给出的解决方案是：仓库内统一使用 LF。在 Windows 系统中，检出（checkout/switch）分支时自动将 LF 转换为 CRLF，提交（add）时自动将 CRLF 转回 LF。
控制这一行为的配置项叫 autocrlf（注意单词 auto）。而文章开头提到的配置项是另一个：safecrlf。
报错信息具体是什么意思？
fatal: LF will be replaced by CRLF — 警告信息表明 Git 检测到需要将 CRLF 转换为 LF，但它拒绝执行转换。
等等，这不合逻辑？
commit 时本就应该将 CRLF 转为 LF，这是正常流程，为何会报错？根源在于 safecrlf 配置（注意单词 safe）。它的作用是检查 CRLF 与 LF 之间的转换是否安全——即评估未来检出时能否将 LF 再转回 CRLF。不幸的是，Git 判断转换不可逆，因此阻止了本次 add 操作。解决方案就是告诉 Git 跳过该检查，即设置 safecrlf = false。
这样修改是否可行？
完全可行。这正是 Git 的默认行为，你的同事们能在 Windows 上顺利开发，仅仅是因为他们从未修改过默认设置。
其他文章可能会建议你执行以下命令检查是否启用了自动转换（注意单词 auto）：
git config --global core.autocrlf该命令不会输出任何结果——因为未配置全局 autocrlf 时返回为空。要查看当前实际值，应使用下面这条命令（将 global 换为 get）：
git config --get core.autocrlf如果返回 true，说明 Git 默认自动转换。你可以在自己机器上验证：若显示 false，请立刻执行下方命令将其改为 true：
git config --global core.autocrlf=true同理，查看 safe 的默认值：
git config --global core.safecrlf
git config --get core.safecrlf你会发现两条命令均无输出。原因很简单——未设置即等于 null，null 在逻辑上等同于 false。回头看看本节标题，答案已不言自明。
部分包管理器无关系统，强制使用 LF
以 pnpm 为例，无论操作系统类型，它都会将 package.json 和 pnpm-lock.json 的换行符统一格式化为 LF。因此，接受现实吧：胳膊拧不过大腿。按照本文的方法修改配置，把节省下来的精力投入到真正重要的技术学习上，不是更好吗？