9

我很难尝试正确合并到分支。分支似乎有行尾问题，因为当我在 Visual Studio 中打开冲突窗口时，它显示了 0 个冲突和多个文件之间的 0 个差异。

我在两个分支上添加了一个 gitattributes 文件，该文件在两个存储库上查找并执行了存储库刷新。

当我刷新两个存储库时，没有任何要提交的更改，即使说明说明会有要提交的更改（本质上是来自 EOL 转换的更改）。

这是我的 gitattributes

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

# Custom for Visual Studio
*.cs     diff=csharp

# Standard to msysgit
*.doc    diff=astextplain
*.DOC    diff=astextplain
*.docx   diff=astextplain
*.DOCX   diff=astextplain
*.dot    diff=astextplain
*.DOT    diff=astextplain
*.pdf    diff=astextplain
*.PDF    diff=astextplain
*.rtf    diff=astextplain
*.RTF    diff=astextplain

我也检查过，我的global core.autocrlf 等于 true（因为我们所有的开发人员都在 Windows 上使用 Visual Studio）

问题是，当我继续执行上述操作以希望跨两个分支修复和规范这些行分支时，我最终会遇到比以前更多的冲突——所有这些都是由于行结束：

在此处输入图像描述

.git/config 文件（不包括分支引用）

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    hideDotFiles = dotGitOnly
    autocrlf = true
[merge]
    renormalize = true

我束手无策，经历了无数 SO 问题/答案 - 谷歌搜索，无济于事 - 我的冲突计数继续上升。

另请注意：我在 TFS 上使用 GIT - 不确定这是否会改变事情。

更新1： 我已经从Visual Studio中复制了所说的“冲突”两个文件，每个文件都复制到他们自己的Notepad ++窗口中，并打开了“显示符号->显示行尾”-然后我比较了两个“冲突”文件和你可以看到行尾没有区别（两个文件都包含完全相同的 CR/LF，如下图所示） - 所以我猜 VS 正在进行其 EOL 转换或其他什么？或者当我将它复制到 Notepad++ 中时，它会进行某种 EOL 转换？不确定这是否有帮助。

在此处输入图像描述

我正在运行 Visual Studio 2015 更新 3

更新 2： 我添加了这个方便的 End of Line Visual Studio 扩展，它显示文件 EOL 字符，因此我可以在合并/差异屏幕中看到所有 EOL 字符，并且看起来它们在文件之间完全匹配。

更新 3： 好的 - 所以我想我可能会在这里做一些事情......我做了一个合并，然后打开了一个冲突的文件，这就是我发现的......我正在合并 FROM 的分支正在使用 CRLF，分支我正在合并 INTO 正在使用 LF - 所以它似乎确实是 EOL 问题。我不确定如何批量解决这个问题？我虽然我上面列出的初始存储库刷新会这样做，但显然不是。

这是主文件（合并到主文件注意：此文件在合并之前是 CRLF，在合并后必须将 CRLF 转换为 LF）： 在此处输入图像描述

这是我要合并的内容： 在此处输入图像描述

4

2 回答 2

2

为了更加一致并且能够通过扩展名指定不同文件的行结尾，您可以使用 .gitattributes 文件。该文件已提交到存储库并将覆盖开发人员设置。.gitattributes 文件应该在存储库的根目录中创建，并像任何其他文件一样提交到存储库中。

# Set behaviour for all files, in case developers don't have core.autocrlf set.
* text=auto

# Explicitly declare text files we want to always be normalized and converted to native line endings on checkout.
*.txt text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.zip binary
于 2017-02-21T17:42:16.967 回答
1

如果您使用 core.autocrlf = true，那么在 repo (TFS) 中，所有文件都使用 LF 存储，而在结帐时，GIT 会将它们转换为 CRLF。我注意到 auto 的问题是根据文档

“使用 CRLF 提交文件后，不会进行任何转换。”

因此，基本上，如果您在存储库中使用 CRLF 提交了一些文件，因为未执行转换，在其他分支中您有标准化的行尾 (LF)，那么您在合并时会收到冲突。很难看到它，因为当您结帐时，LF 被替换为 CRLF 并且似乎没有任何变化。

我的方法是使用 CRLF 作为 eol 而不是 auto，希望它总是在提交时替换 CRLF -> LF 和在结帐时替换 LF -> CRLF。

*.cs                  text eol=crlf
*.xaml                text eol=crlf
*.csproj              text eol=crlf
*.sln                 text eol=crlf

因此，要解决您的问题，您必须将服务器行尾从 CRLF 更改为 LF。对我来说，这个命令有效.gitattributes 被修改并提交（即使我无法解释它，但我将所有带有 CRLF 的文件在存储库上更改为 LF）

git rm --cached -rf .
git diff --cached --name-only -z | xargs -n 50 -0 git add -f

还有一件事，在更改 .gitattributes 之后，您必须再次签出文件，我正在使用以下命令：

git rm -rf --cached .
git reset --hard HEAD
于 2017-02-24T08:17:33.810 回答