使用.gitattributes条目
* text=auto
签出文本文件时使用哪些行分隔符？ documentation州：
设置为字符串值＆＃34;自动＆＃34;
当文本设置为＆＃34; auto＆＃34;时，路径将标记为自动行结束转换。如果Git决定内容是文本，那么 在结账时，行结尾将转换为LF。当文件已经存在 使用CRLF提交，不进行任何转换。
未指定的
如果未指定text属性，Git使用core.autocrlf配置变量来确定是否应该转换文件。
对我来说，text=auto core.autocrlf无关紧要。我是对的吗？
答案 0 :(得分：5)
对我来说，如果
text=auto[在.gitattributes中，[{1}} [在配置中]并不重要。我是对的吗？
清除。 The git config documentation现在说core.autocrlf：
将此变量设置为＆＃34; true＆＃34;与将
core.autocrlf属性设置为＆＃34; auto＆＃34;相同在所有文件和core.eol到＆＃34; crlf＆＃34;。 ...此变量可以设置为 input ，在这种情况下不会执行输出转换。
对于text本身来说，git config文件说，只是前几行，令人困惑地说：
设置要在工作目录中使用的行结束类型，以便在core.autocrlf为false时将
core.eol属性设置为的文件 [我告诉你没有关于何时设置为text或true] ...有关行尾转换的详细信息，请参阅gitattributes(5)。
（粗体和括号内的文字）。然而，input关于有效设置core.autocrlf的说明，以及当core.eol为core.autocrlf或true时 会发生什么 }，和 input设置为core.eol？
如果我们转向the gitattributes documentation，我们会发现这句话隐藏起来：
要控制工作目录中使用的行结束样式，请对单个文件使用
crlf属性，对所有文本文件使用eol配置变量。请注意，core.eol会覆盖core.autocrlf
因此，如果您没有设置core.eol，则此不会覆盖core.autocrlf。这意味着无论你选择core.eol作为默认值。但是，如果您执行设置core.eol，则无论您为core.autocrlf设置选择什么，都会忽略
Git中的实际源代码非常曲折（并且多年来经历了许多变化）。但是，有一些事情可以说是在所有Git变体中都是如此：
转换通常 1 只发生在两个地方：将文件从索引复制到工作树（＆＃34;输出＆＃34;阶段），或者将文件从工作树复制到索引（＆＃34;输入＆＃34;阶段）。输出端副本发生在core.eol和git checkout期间，这两个副本都将文件从索引复制到工作树。输入端副本发生在git checkout-index期间，它将文件从工作树复制到索引。
一个被认为是＆＃34;二进制文件＆＃34;不会被修改。一个被认为是＆＃34;文本＆＃34;是修改的候选人。
因此，git add表示所有文件都成为修改的候选对象，* text=auto具有相同的效果。但究竟应用了哪些修改？那部分很棘手。假设两个不同配置文档部分的上述引用对于所有Git版本都是正确的：
core.autocrlf设置具有特定 .gitattributes，则eol=设置会没关系。但这与core.eol .gitattributes设置无关
text=设置，您的有效eol=设置就会控制这些转化的内容。因此，由于core.eol可以更改有效的core.autocrlf设置，和，您可以忽略为某些{{1}设置特定的设置设置core.eol的文件可能就像将text设置更改为core.autocrlf，即使您已为所有设置了core.eol文件。 （如果将crlf设置为text=auto会发生什么情况需要仔细测试。）
1 这个词通常是，因为这里讨论了文件在进出Git的过程中转换的位置。但是，对于某些操作，例如core.autocrlf针对工作树，或input使用＆＃34;规范化＆＃34;启用后，Git必须进行虚拟登记＆＃34;或者＆＃34;虚拟登记和退房＆＃34;，在这种情况下Git会做一些额外的转换。不幸的是，为什么 Git中的实际代码非常曲折。