我遇到的问题是合并冲突导致整个文件发生冲突。这最终导致本地文件的换行符在合并时变为unix样式换行符（LF）在合并之前，开发和功能分支在签出时都有CRLF换行符。
如果我跑了
git rm --cached -r .
git add -A
git状态不会显示任何更改。但是，当我删除.gitattributes文件并执行另一个删除全部/添加所有文件时，导致某些文件使用不同的新行进行更新。例如，对于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设置如何。一个的优点 .gitattributes文件是您的线路配置关联的 与您的存储库
这清楚表明.gitattributes能够覆盖autocrlf，但是没有任何设置可以告诉它进行任何eol转换。也许隐含使用了一些默认值。
答案 0 :(得分：1)
我意识到这是一个老问题，但答案可能对有相关问题的人有用。
gitattributes文件指定＆＃34; -text＆＃34;对于* .csproj和* .sln文件。这意味着对于那些文件，不应该进行EOL转换。
另一方面，您还使用了配置＆＃34; autocrlf = true＆＃34;。此设置意味着：将具有LF行结尾的文件存储在Git存储库中，并将具有本机行结尾的文件存储在工作目录中。
所以：在添加gitattributes文件之前，由于autocrlf设置，* .csproj和* .sln文件与Git仓库中的LF行结尾一起存储。添加gitattributes文件并在工作目录中检出这些文件后，不会进行EOL转换，这些文件最终会在工作目录中以LF行结尾。