0

我遇到了合并冲突导致整个文件发生冲突的问题。这最终导致本地文件的换行符在合并时都变成了 unix 样式的换行符（LF）（在合并之前，开发和功能分支在签出时都有 CRLF 换行符）。

如果我跑

git rm --cached -r .
git add -A

git status 不会显示任何更改。但是，当我删除该.gitattributes文件并再次删除所有/添加所有文件时，它导致某些文件被更新为不同的新行。例如对于一个 100 行的文件，它会说 100 行被删除，100 行被添加。在对两个分支执行此操作后，合并就很好了。

.gitconfigautocrlf = 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

或者，您可以通过配置一个特殊的 .gitattributes 文件来配置 Git 在每个存储库的基础上管理行尾的方式。该文件被提交到存储库并覆盖个人的 core.autocrlf 设置，确保所有用户的行为一致，无论他们的 Git 设置如何。.gitattributes 文件的优点是您的行配置与您的存储库相关联

这清楚地表明 .gitattributes 能够覆盖 autocrlf，但其中没有设置告诉它进行任何 eol 转换。也许有一些隐式使用的默认值。

4

1 回答 1

1

我意识到这是一个老问题，但答案可能对有相关问题的人有用。

gitattributes 文件指定-text* .csproj和 * .sln文件。这意味着对于这些文件，不应进行 EOL 转换。

另一方面，您也使用了配置autocrlf = true。该设置意味着：将带有 LF 行结尾的文件存储在 Git 存储库中，并将带有原生行结尾的文件存储在工作目录中。

因此：在添加 gitattributes 文件之前，由于 autocrlf 设置，* .csproj和 * .sln文件以 LF 行结尾存储在 Git 存储库中。添加 gitattributes 文件并在工作目录中检出这些文件后，没有进行 EOL 转换，并且这些文件在工作目录中以 LF 行结尾结束。

于 2015-03-03T23:15:31.993 回答