一篇文章带你把Git换行符转换弄明白，以及如何Git设置处理换行符行为

详细解释了换行符带来影响以及Git 如何设置换行符，以及core.autocrlf 和 core.eol 如何控制换行符转换。

问题描述

Git 报告错误“我注意到你这个文件是 LF 格式，但下一次我操作这个文件时会改成 CRLF，你要小心可能会导致变化。”，警告分析。

 warning: in the working copy of 'docs/人工智能/第一章.html', LF will be replaced by CRLF the next time Git touches it

Git 认为：这个文件的换行符不符合本地预期格式（CRLF），所以提示你：

可以判断出你当前的 Git 设置启用了 自动换行符转换，也就是：

 core.autocrlf = true

这表示：

• 当你从 Git 仓库中 检出（checkout）文件时，Git 会把其中的 LF 换行符转为 CRLF（Windows 标准）。

• 当你 提交（commit）文件时，Git 又会把本地的 CRLF 转回 LF，以保持仓库中统一使用 LF。

优点（适合 Windows 用户）

这种方式能让你在 Windows 本地用熟悉的 CRLF 编辑文件，而仓库中统一保存为 LF，避免跨平台问题。

查看git 默认设置

 git config --get core.autocrlf
 true

你想消除这类警告，可以在仓库根目录添加 .gitattributes 文件来明确控制每种文件的换行规则，例如：

 *.html text eol=lf
 *.js   text eol=lf
 *.css  text eol=lf

这样 Git 就知道不需要再发出自动替换的警告了，他的作用就是强制LF格式保存。

举例子：

脚本语言（如 Python、Shell 脚本）

• 换行符不一致可能会导致某些脚本无法正确执行，特别是在 Windows 和 Linux 之间：

  • Unix/Linux 系统的脚本文件（如 .sh 或 .py）期望使用 LF 换行符。如果你在 Windows 上创建或修改了脚本并使用了 CRLF（Windows 格式），某些 Linux 系统可能会在执行时出现错误，无法识别文件结尾。

  • 在 Windows 环境下执行 Bash 脚本（如使用 Git Bash 或 Cygwin）时，CRLF 可能会导致文件格式错误，进而影响执行。

  解决方案：

  • 使用 Git 的 core.autocrlf=true 或在 .gitattributes 文件中为脚本文件强制使用 LF (text eol=lf)。

  • 在编辑器中确保脚本文件使用 LF 换行符。

编译语言（如 C/C++、Java）

• C/C++ 和 Java等编译语言对换行符没有特别的敏感性。它们通常会忽略换行符，而更关注语法和结构。

  • 只要文件中的换行符不影响程序的语法结构，代码就能正常编译和运行。

  但是，某些情况下，如果换行符不一致，可能会在处理文件输入输出时带来问题。例如，在文件操作时，读取一个 Windows 格式的文件（CRLF）到 Linux 环境，可能会导致额外的换行字符出现在输出中

反复触发 Git 变更场景

• 你在 Windows 上打开某个使用 LF 的文件，编辑器可能会自动改为 CRLF，然后你没做任何实质性修改，Git 也会显示“文件已修改”。

• 提交后，Git 会再转回 LF，来回循环，导致提交记录中频繁出现“只是换行符不同”的伪变更。

建议保持一致

Git 设置为保持一致

 git config --global core.autocrlf false

Git 将保留文件的原始换行符，不做自动转换。这样原来什么样就是什么样，用户需要自行处理换行符。程序员需要在编译器中指定刚结束符，这是最好的 。需要什么指定什么，这才是程序员。

Sublime 修改换行符

core.autocrlf 和 core.eol 设置

都是用于设置转换方式的，不过一但被 .gitattributes 明确指定了 eol=lf（或 eol=crlf），Git 会忽略 core.autocrlf 的设置，以 .gitattributes 为准。

是否在 .gitattributes 指定 eol？	Git 是否转换换行符？	以哪种换行符签出？
是（如 eol=lf）	是（提交为 LF，签出为 LF）	LF
否（未设置 eol）	看 core.autocrlf 配置	由系统决定（或受 core.eol 影响）

总结

对于计算机直接执行的程序代码而言，换行符的差异通常不会产生实质性影响。但对于依赖字符级解析的配置文件或文本格式处理程序来说，换行符的差异（如 LF 与 CRLF）可能导致识别错误。例如：如果程序通过识别换行符来判断一行数据的起止位置，那么在换行符被隐式修改的情况下，将会导致逻辑判断失败。

这种问题常见于文件在不同操作系统或编辑器中被打开后，自动更改了换行符格式。虽然文件内容看起来仍然是“逐行”的文本，但底层的换行标识已发生变化。

Git 对文件的改动检测是基于内容哈希计算的，因此即便你没有主动修改代码，仅仅是换行符被改变，也会被 Git 识别为文件内容发生了更改。在提交或上传时，Git 可能会根据配置自动统一换行符（如 core.autocrlf 设置），从而导致一些“看似无改动”的文件也被标记为已修改，引发困扰。

建议

• 对于跨平台协作项目，应统一团队的换行符策略，并在 .gitattributes 文件中明确指定（如：text=auto 或 .txt text eol=lf）。

• 避免使用可能自动更改换行符的编辑器设置，或明确配置编辑器统一换行风格。

• 留意 Git 的 core.autocrlf 和 core.eol 设置，合理配置可避免不必要的换行符变动。