的Git +的Windows + Visual Studio的合并通过线引起的冲突，我有困难的时候试图适当合并，分支机构分支机构

之间

结束的问题。分支似乎有行结束的问题，因为当我在Visual Studio中打开冲突窗口时，它显示了多个文件之间的0冲突和0差异。的Git +的Windows + Visual Studio的合并通过线引起的冲突，我有困难的时候试图适当合并，分支机构分支机构

我在两个分支，看起来和两个仓库进行repository refresh增加了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 is equal to 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中，每个复制的说：“冲突的”两个文件到各自的记事本+窗户“显示符号 - >行尾显示”打开 - 然后我对比这两个“冲突”的文件，正如你可以看到，行结尾没有差异（两个文件都包含完全相同的CR/LF，如下图所示） - 所以我猜测VS正在进行EOL转换或其他？或者当我将它复制到Notepad ++中时，它会进行某种EOL转换？不知道这是否有帮助。

我在运行Visual Studio 2015年更新3

更新2： 我已经添加了这个方便End of Line Visual Studio Extension，显示了文件的EOL字符，这样我就可以看到所有的EOL字符在合并/差异屏幕右边，看起来它们完全匹配在文件之间。

更新3： OK - 所以我想我可能会到的东西在这里......我的合并，然后打开一个冲突的文件，这是我发现了什么......分支我正在合并FROM正在使用CRLF，我正在合并INTO的分支正在使用LF - 所以它似乎是和EOL问题。我不知道我该如何批量修复这个问题呢？我虽然我上面列出的初始仓库刷新将做到这一点，显然不是。

这里是主（合并到主注：这个文件是CRLF之前合并，合并后的CRLFs必须被转换为LF）：

这里就是我从合并：

来源

2017-02-20 99823

您正在使用哪个版本的Visual Studio（包括更新版本 - 例如Visual Studio 2015更新4）？在Visual Studio中，如果将选项切换为“忽略修剪空白”更改，是否显示diff中的任何更改？ – jamill

我用我的视觉工作室版本更新了我的问题。此外，我很难找到该选项的位置 - 在哪里？ – 99823

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

# 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-21 17:42:16

嗨大卫 - 我实际上已经有一个gitattributes文件 - 我的原始问题中指定。有什么我应该改变我目前使用的文件？ – 99823

嗨 - 是的，尝试从文件中删除＃Custom for Visual Studio部分。 –

我已经按照你的建议更改了gitattributes文件，在我的原始问题中执行了一个存储库刷新链接，做了一次合并，并且包含所有LF的主文件和包含所有CRLFS的分支合并的相同数量的冲突显示 - 基本上没有任何变化，我处于相同的位置。 – 99823

如果您正在使用core.autocrlf = true，则在回购（TFS）的所有文件都存储与LF，而在结账GIT将它们转换成CRLF。我用汽车注意到的问题是根据documentation

“当使用CRLF提交文件时，没有转换完成。”

所以基本上如果你有一些库中的文件提交CRLF，因为没有执行转换，在其他分支你有规范化行尾（LF），那么你会收到冲突uppon合并。很难看到它，因为当你签出时，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进行了修改和COMMITED（即使我无法解释，但我得到了所有的文件与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-24 08:17:33 3615

的Git +的Windows + Visual Studio的合并通过线引起的冲突，我有困难的时候试图适当合并，分支机构分支机构

回答

相关问题