Git有几个不同的设置来控制行尾的工作方式。
首先，在.gitattributes文件中，有text，如果设置，则表示文件为文本，需要进行行尾转换;如果不设置，则表示文件为二进制，不需要进行行尾转换;如果设置为auto，则意味着Git应该根据文件开头的内容进行猜测。通常Git会正确猜测，但由于性能原因，它不会读取整个文件，因此有时会猜错（特别是在PDF上）。
其次，.gitattributes文件中有eol属性。如果设置为crlf，则文件在存储库中具有LF结尾，在工作树中具有CRLF结尾;如果设置为lf，则文件在存储库和工作树中都具有LF结尾;如果未设置，则具有默认值（如下所述）。请注意，如果未显式或隐式设置text，则eol无效。
这些都是可以使用的选项，事实上，它们是首选的。通常情况下，在工作树中使用什么行尾并不重要，因此text被设置而eol未设置。然而，对于某些类型的文件，这很重要。Shell文件必须始终使用LF，Windows批处理文件必须始终使用CRLF;否则，它们根本不起作用。因此，您总是希望为它们指定eol。
如果未指定eol，则系统上工作树的默认行结尾由core.eol设置指定，可以是lf、crlf或native（默认值）。
现在，在某些情况下，您没有指定text属性。在这种情况下，其默认值取决于core.autocrlf。如果该选项设置为true，则相当于默认为text=auto，core.eol为crlf。如果设置为input，那么除非.gitattributes另有说明，否则不会执行转换。如果您在Windows上有用户，这几乎肯定会导致存储库中的CRLF，这可能是您不希望的，因为它会导致差异上丑陋的^M标记和Git工具产生空白警告。
如果你不确定要做什么，就在你的项目中使用.gitattributes，它总是能正常工作。通常使用* text=auto就足够了，尽管有时你会想要不同的东西，如上所述。这将导致你想要的情况：其中Unix用户在存储库和工作树中使用LF，Windows用户在存储库中使用LF，在工作树中使用CRLF，除非他们在系统上配置了不同的行尾（这很好）。