这只是一个变通的解决方案:

在正常情况下，使用git附带的解决方案。这些在大多数情况下都很有效。如果您通过设置.gitattributes在Windows和Unix系统上共享开发，则强制到LF。

以我为例，有10个程序员在Windows上开发一个项目。该项目与CRLF进行了核对，没有强制到LF的选项。

一些设置是在我的机器内部编写的，对LF格式没有任何影响;因此，在每次小文件更改时，一些文件被全局更改为LF。

我的解决方案:

windows机器: 让一切顺其自然吧。什么都不关心，因为你是一个默认的windows“独狼”开发人员，你必须处理这样的问题:“在这个广阔的世界上没有其他系统了，是吗?”

unix机器上

Add following lines to a config's [alias] section. This command lists all changed (i.e. modified/new) files: lc = "!f() { git status --porcelain \ | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \ | cut -c 4- ; }; f " Convert all those changed files into dos format: unix2dos $(git lc) Optionally ... Create a git hook for this action to automate this process Use params and include it and modify the grep function to match only particular filenames, e.g.: ... | egrep -r "^(\?| ).*\.(txt|conf)" | ... Feel free to make it even more convenient by using an additional shortcut: c2dos = "!f() { unix2dos $(git lc) ; }; f " ... and fire the converted stuff by typing git c2dos

使用核心。当我在Visual Studio 2010项目中检出文件时，selflf =false会阻止所有文件被标记为更新。开发团队的另外两名成员也使用Windows系统，因此混合环境没有发挥作用，但存储库附带的默认设置总是将所有文件标记为克隆后立即更新。

我认为最重要的是找到适合您的环境的CRLF设置。特别是在我们的Linux盒子上的许多其他存储库中，设置selff = true会产生更好的结果。

20多年后，我们仍然在处理操作系统之间的行尾差异……伤心。

除非你真的知道你在做什么，否则你几乎总是需要selff =input。

下面是一些附加的上下文:

It should be either core.autocrlf=true if you like DOS ending or core.autocrlf=input if you prefer unix-newlines. In both cases, your Git repository will have only LF, which is the Right Thing. The only argument for core.autocrlf=false was that automatic heuristic may incorrectly detect some binary as text and then your tile will be corrupted. So, core.safecrlf option was introduced to warn a user if a irreversable change happens. In fact, there are two possibilities of irreversable changes -- mixed line-ending in text file, in this normalization is desirable, so this warning can be ignored, or (very unlikely) that Git incorrectly detected your binary file as text. Then you need to use attributes to tell Git that this file is binary.

上面这段话最初是从gmane.org上的一个帖子中截取的，但现在已经删除了。

不要转换行结束符。VCS的工作不是解释数据——只是存储和版本它。每个现代文本编辑器都可以读取这两种行尾。

这是Windows和Visual Studio用户与Mac或Linux用户共享代码的两个选项。要了解更详细的解释，请阅读gitattributes手册。

* text = auto

在你的repo .gitattributes文件中添加:

*   text=auto

这将正常化所有的文件与LF行结束在回购。

取决于您的操作系统(核心。eol设置)，工作树中的文件将被标准化为基于Unix系统的LF或基于Windows系统的CRLF。

这是Microsoft . net回购所使用的配置。

例子:

Hello\r\nWorld

将在回购中始终归一化为:

Hello\nWorld

签出时，Windows中的工作树将被转换为:

Hello\r\nWorld

签出时，Mac中的工作树将保留为:

Hello\nWorld

注意:如果您的repo已经包含了未规范化的文件，那么当您下次对这些文件进行任何更改时，git状态将显示这些文件已完全修改，这可能会让其他用户稍后合并他们的更改。有关详细信息，请参见更改行结束符后刷新存储库。

核心。独裁者= true

如果文本在. Git attributes文件中未指定，Git使用核心。selflf配置变量，以确定是否应该转换文件。

对于Windows用户，git配置——global core。专制是一个很好的选择，因为:

文件只有在添加到repo时才被归一化为LF行结束符。如果在repo中有未规范化的文件，此设置将不会触及它们。 所有文本文件都转换为工作目录中的CRLF行结束符。

这种方法的问题在于:

If you are a Windows user with autocrlf = input, you will see a bunch of files with LF line endings. Not a hazard for the rest of the team, because your commits will still be normalized with LF line endings. If you are a Windows user with core.autocrlf = false, you will see a bunch of files with LF line endings and you may introduce files with CRLF line endings into the repo. Most Mac users use autocrlf = input and may get files with CRLF file endings, probably from Windows users with core.autocrlf = false.

试着设定核心。自专制配置选项为true。还要看看核心。safecrlf选项。

实际上它听起来像核心。Safecrlf可能已经在你的存储库中设置了，因为(强调我的):

如果这不是当前设置的核心的情况。专制者，git将拒绝文件。

如果是这种情况，那么您可能需要检查您的文本编辑器是否配置为一致地使用行结束符。如果文本文件混合包含LF和CRLF行结束符，您可能会遇到问题。

最后，我觉得在Windows上简单地“使用您所给予的”和使用LF终止行的建议会导致比它解决的问题更多的问题。Git有上述选项来尝试以合理的方式处理行结束符，因此使用它们是有意义的。