我真的很困惑“检查代码”在下一页中的含义：https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#__code_core_autocrlf_code
如果您使用的是Windows计算机，请将其设置为true - 这会在您签出代码时将LF结尾转换为CRLF：
这是否意味着你添加文件？因为无论何时我将core.autocrlf从input更改为true，反之亦然，我在添加文件时看到的差异（“签出”是否意味着“添加”？）：
> git config --global core.autocrlf true
> git add crlf-file.md
> git add lf-file.md
warning: LF will be replaced by CRLF in lf-file.md.
The file will have its original line endings in your working directory.
> git config --global core.autocrlf input
> git add crlf-file.md
warning: CRLF will be replaced by LF in crlf-file.md.
The file will have its original line endings in your working directory.
> git add lf-file.md
（注意：我正在尝试回答基本问题，这似乎真的是：如果结账意味着git checkout，为什么我在git add期间收到这些消息？）
关于这一点的文档有点草率，可能是故意的，因为完全正确的细节有点模糊。要在概念层面上理解它，您应该将行结束修改视为更一般的涂抹和清理过滤的一部分（因为这实际上是它的实现方式）。
在Git中，您目前可以使用的每个文件同时存在于三个位置：
the HEAD commit the index the work-tree
--------------- --------- -------------
README.md README.md README.md
file.txt file.txt file.txt
可以在各个方向复制文件，但所有提交始终是只读的。因此，您可以从HEAD提交复制到索引，或从索引复制到工作树。您还可以从工作树复制到索引中。
（你也可以从索引中创建一个新的提交。这会留下旧的HEAD提交，新的提交变成HEAD提交。所以在进行新的提交之后，HEAD提交和索引匹配。这不是因为我们修改了任何提交;我们不能这样做。这是因为我们添加了一个新的提交，由索引创建，然后我们停止调用旧提交HEAD并将新的提交调用HEAD而不是。）
请注意，索引位于HEAD和工作树之间“在路上”。为了将任何文件从HEAD复制到工作树，它必须首先通过索引。为了从工作树进行新的提交，每个新文件必须通过索引。因此，索引/工作树转换是清洁和污迹发生的地方。
“清理”文件意味着准备好提交。例如，该清洁过程可以将CRLF线路末端转换为仅LF线路末端。 Or, using the ident filter, you can un-make many substitutions，或编写自己的过滤器来做任何事情。涂抹文件意味着准备好在工作树中进行编辑和/或使用。例如，这可以将仅LF的行结尾转换为CRLF结尾。与清洁过程一样，您可以使用ident过滤器或您自己的过滤器驱动程序来执行您想要的任何操作。 Git LFS使用这些驱动程序来交换短引用和整个文件内容。
因此，确切的答案是在将文件复制到索引中或从索引中复制出来的进程中应用行结束转换。最常见的是这两个：
git add从工作树复制到索引。git checkout提取到工作树，从提交到索引再到工作树，或直接从索引到工作树。只有在这些时候才会发生这些CRLF到LF或LF到CRLF的转换。但是Git有额外的代码试图直观地说，以后进行这些转换是否会导致对现有提交数据的更改，即使它还没有完成。该代码将为您提供您所看到的警告消息：
warning: LF will be replaced by CRLF ...
warning: CRLF will be replaced by LF ...
如果启用“safe crlf”选项，则会出现这些警告。因为它们来自不同时间运行的不同代码，所以一切都会非常混乱。
请注意，当end of line conversion warnings设置为core.safecrlf或true时看到的那些warn在结账时并不总是有效，因为对于不使用CRLF作为行结尾的内容，它可能会被错误地触发。
这已在Git 2.16（2018年第一季度）中修复
请参阅由commit 649f1f0撰写的commit 86ff70a（2017年12月8日）和Torsten Bögershausen (tboegi)（2017年11月26日）。
（Junio C Hamano -- gitster --于2017年12月27日在commit 720b176合并）
convert：收紧安全的autocrlf处理当一个文本文件已经与CRLF一起提交并且该文件再次被提交时，如果
.gitattributs具有“text=auto”，则保留CRLF。 这是通过分析存储在索引中的blob的内容来完成的：如果找到'\r'，Git假定blob是与CRLF一起提交的。简单搜索'
\r'并不总是按预期工作： 文件以UTF-16编码，带有CRLF并被提交。 Git将其视为二进制。 现在内容转换为UTF-8。在下一次提交时，Git将文件视为文本，CRLF应该转换为LF，但不是。用
has_cr_in_index()替换has_crlf_in_index()。如果没有找到'\ r'，则直接返回0，这是最常见的情况。 如果找到'\r'，则会更深入地分析内容。
考虑一个图书馆。当您从图书馆查看图书时，在您重新检查之前，没有其他顾客可以访问该图书。
较旧的集中版本控制系统的工作方式类似当您“签出”某个文件时，系统会锁定该文件，其他任何用户都无法检出同一个文件，直到您重新签入该文件为止。
较新的版本控制系统倾向于允许多个用户同时处理文件，要求将不兼容的更改合并在一起，而不是严格序列化对文件的访问。但是，仍然使用术语“签出”来指示将文件从存储库复制到工作目录的过程。