问了这个问题快四年了，我终于找到 了一个让我完全满意的答案 ！

请参阅 github:help 处理行尾的指南中 的详细信息。

Git 允许您直接使用文件中 的text 属性 .gitattributes 为 repo 设置行结束属性。该文件被提交到 repo
并覆盖core.autocrlf设置，允许您确保所有用户的行为一致，而不管他们的 git 设置如何。

因此

这样做的好处是您的终端配置现在随您的存储库一起传输，您无需担心协作者是否具有正确的全局设置。

这是一个 .gitattributes 文件的例子

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

对于最流行的编程语言，有一个方便的即用型 .gitattributes
文件集合。帮助您入门很有用。

一旦你创建或调整了你的 .gitattributes
，你应该执行一次一劳永逸的行尾重新规范化。

请注意，在您在应用中打开项目的 Git 存储库后， GitHub 桌面应用可以建议和创建文件。
.gitattributes 要尝试这样做，请单击齿轮图标（在右上角）> 存储库设置 …> 行尾和属性。您将被要求添加推荐的
.gitattributes 内容，如果您同意，该应用程序还将对您的存储库中的所有文件执行规范化。

最后，请注意行尾文章提供了更多背景信息，并解释了 Git 在手头的问题上是如何演变的。我认为这是 必读 的。

您的团队中可能有用户使用 EGit 或 JGit（Eclipse 和 TeamCity
等工具使用它们）来提交他们的更改。然后你不走运，正如@gatinueta 在这个答案的评论中解释的那样：

如果您的团队中有使用 Egit 或 JGit 的人，此设置将无法完全满足您的要求，因为这些工具只会忽略 .gitattributes 并愉快地签入
CRLF
文件https://bugs.eclipse.org/bugs/show_bug.cgi?编号=342372

一个技巧可能是让他们在另一个客户端中提交他们的更改，比如SourceTree。那时，我们的团队在许多用例中更喜欢使用该工具而不是
Eclipse 的 EGit。

谁说软件很简单？：-/