我遇到了一个问题，合并冲突导致整个文件发生冲突。最终，本地文件的换行符在合并时都变成了unix风格的换行符（LF）（在合并之前，开发和功能分支在签出时都有CRLF换行符）。
如果我运行
git rm --cached -r .
git add -A
git状态不会显示任何更改。但是，当我删除.gitattributes文件并执行另一个remove-all/add-all操作时，会导致某些文件被更新为不同的新行。例如，对于一个100行的文件，它会说删除了100行，添加了100行。对两个分支都这样做后，合并就可以了。
.gitconfig autocrlf = true已设置，而.gitattributes文件只有这些行。我认为以下几条线只会影响合并战略。
*.csproj -text merge=union
*.sln -text merge=union
为什么这个.gitattributes会改变新行的提交方式
同样，在autocrlf设置为true的情况下，我不确定为什么合并会比较LF和CRLF，除非.gitattributes中有什么东西覆盖了它。
发件人https://help.github.com/articles/dealing-with-line-endings
或者，您可以配置Git管理通过配置一个特殊的.gitattributes文件，以每个存储库为基础。此文件被提交到存储库中，并覆盖个人的core.autocrlf设置，确保所有用户，无论其Git设置如何。a的优势.gitattributes文件是您的行配置关联的使用您的存储库
这清楚地表明，.gitattributes能够覆盖autocrlf，但其中没有任何设置告诉它进行任何eol转换。也许有一些默认值是隐含使用的。
我意识到这是一个老问题，但答案可能对有相关问题的人有用。
gitattributes文件为*.csproj和*.sln文件指定-text。这意味着对于这些文件，不应该进行EOL转换。
另一方面，您还使用了配置autocrlf = true。此设置意味着：将LF行尾的文件存储在Git存储库中，将本机行尾的文档存储在工作目录中。
因此：在添加gitattributes文件之前，由于autocrlf设置，*.csproj和*.sln文件以LF行结尾存储在Git repo中。在添加gitattributes文件并在工作目录中签出这些文件后，不会进行EOL转换，这些文件在工作目录中将以LF行结尾。