关于CRLF和LF和Git的行尾管理_git 下载lf结尾

定义

LF：换行
LF（Line Feed）代表“换行”，但你可能更熟悉术语换行符（转义序列 \n）。简单地说，这个字符代表一行文本的结束。在 Linux 和 Mac 上，这相当于新文本行的开始。这种区别很重要，因为 Windows 不遵循此约定。我们了解回车之后再讨论为什么不同。

CR：回车
CR（Carriage Return）代表回车（转义序列\r），将光标移动到当前行的开头。终端上的下载进度条就是通过CR实现的，通过使用回车符，你的终端可以通过将光标返回到当前行的开头并覆盖任何先前呈现的文本来将文本动画化

Git中的行尾

我们从前面可以知道CRLF和LF是不同的字符表示，因此缺少通用行结尾为 git 等版本控制软件带来了麻烦，这类软件依赖于非常精确的字符比较来确定文件自上次签入以来是否发生了变化。如果开发人员使用 Windows 并且另一个使用 Mac 或 Linux，他们每个人都保存和提交相同的文件，他们可能会在他们的 git diff 中看到行结束更改——从 CRLF 到 LF 的转换，反之亦然。由于单字符更改，这会导致不必要的麻烦，非常烦人。

使用 core.autocrlf 在 Git 中配置行尾

可以使用core.autocrlf配置告诉git如何处理系统上的行尾。可以通过以下命令完成：

git config --global core.autocrlf [true|false|input]
1

注意，false值会关闭行尾转换，这通常是不可取的，除非是团队中的每个人都使用相同的操作系统。当然，我觉得这种情况很少发生，所以慎用（除非你使用 .gitattributes 配置，在这种情况下，它会优先于你的 git 配置——稍后会详细介绍）。

所以，一般来说我们只有两个选择：autocrlf true 和 autocrlf input

autocrlf true

当 autocrlf 为 true 时（git默认行为），文件将使用 git 在本地检出为 CRLF，但是每当你提交文件时，CRLF 的所有实例都将替换为 LF。基本上，此设置可确保你的代码库在所有文件的最终版本中始终使用 LF，但在获取时在本地使用 CRLF。这是 Windows 开发人员的推荐设置，因为 CRLF 是 Windows 的本机行结尾。

autocrlf input

使用 autocrlf input，文件在提交时转换为 LF，但在获取时不会转换为任何内容。因此名称为“输入”——你得到是你最初输入的内容。如果一个文件最初被 Windows 开发人员意外提交为 CRLF，你会在本地看到它是 CRLF（如果你修改它，你会强制它变成LF）。如果文件最初是作为 LF 添加的，您会看到它是LF。这通常是一件好事，因为这意味着你将始终在代码库中获得 LF 行结尾（假设你从一开始就使用它）。

input 和 ​​true 之间的唯一区别是输入不会在本地获取时处理行尾。这是 Mac/Linux 开发人员的推荐设置，因为这些操作系统默认使用 LF。

参考

https://zhuanlan.zhihu.com/p/380574688