use*_*473 2 c# git github visual-studio-2013
我和一个朋友正在使用VS 2013使用Git编写一个用C#编写的项目(不是 VS Git插件,请注意),我们遇到了问题.我们的工作流程设置如下:我们有一个中央存储库,我们每个都有自己的存储库分支,我们单独处理.当我们的个人工作完成后,我们将推送到中央存储库.当我们想要与中央存储库同步时,我们拉.
问题是,当我们拉,csproj文件随机更新.有时它们会正确更新,并且自上次拉取后添加的文件正确显示在VS中,有时csproj文件完全不受影响.
这很奇怪,因为csproj在其他任何地方都得到了正确的更新,包括中央存储库,它有时在我们拉动时不能正确更新.
在我们的.gitattributes文件中,我们.csproj设置为merge=union.
我们拉的时候执行的命令是git pull upstream在那里upstream只是一个远程指向我们的中央资料库.
有任何想法吗？
我将根据Edward Thomson的评论将其作为答案,其中包含此链接到csproj文件中的合并冲突(haacked.com/archive/2014/04/16/csproj-merge-conflicts).请注意,我对Visual Studios,C#或Windows一无所知,但我确实知道git.:-)
问题是,当我们拉,csproj文件随机更新.有时它们会正确更新,并且自上次拉取后添加的文件正确显示在VS中,有时csproj文件完全不受影响.
首先,我们来做一些简短的评论说明:
git pull只是git fetch其次git merge.你可以告诉Git做一个rebase.根据您的开发流程,这可能是一个好主意,但不会改变这个特定问题,因为...git rebase使用合并机制.git push)从不进行任何合并,所以你只能看到"我和其他人做了什么之后让我得到新东西"的问题.即使这样,你是否看到问题在很大程度上取决于你和别人做了什么.这是因为合并机械,通过使用两个git merge及git rebase,只是没有那么聪明.现在让我们来看看底层问题,它(基于链接)是这些*.csproj文件包含XML:结构化数据,git的内置面向文本的合并操作无法正确合并.
当在git diff输出中两个不同的开发线(合并的分支或提交)对单个文件的相同区域进行不同的更改时,更改冲突.当两个编辑者无法就拼写达成一致时,一个典型的例子出现在文件中.例如,我之前做了这个改变:
diff --git a/plates.tex b/plates.tex
index 09939ca..3dfc610 100644
--- a/plates.tex
+++ b/plates.tex
@@ -15,7 +15,7 @@ that I took on a trip to parts of Australia in February of 2010
\end{plate*}
The kangaroo is probably the most widely known marsupial.
There are actually four species of large kangaroo:
-the red, the eastern and western gray, and the antilopine.
+the red, the eastern and western grey, and the antilopine.
There are also smaller tree-kangaroos and rat-kangaroos.
\begin{plate*}[h]
如果我要把这个与其他对diff中显示的任何一行进行不同更改的人合并,但是留下"灰色"字母拼写a,我会发生冲突.例如,如果我的编辑要坚持拼写"kangaru"这个词,那么这些变化就会发生冲突:
Auto-merging plates.tex
CONFLICT (content): Merge conflict in plates.tex
Automatic merge failed; fix conflicts and then commit the result.
当git遇到冲突的变化时,通常的反应是简单地声明存在冲突并停止. 它给你留下一个工作树版本包含冲突标记的文件的<<<<<<< ======= >>>>>>>周边冲突双方(与|||||||基础版本上面当且仅当您设置merge.conflictstyle于diff3):
\end{plate*}
<<<<<<< HEAD
The kangaru is probably the most widely known marsupial.
There are actually four species of large kangaru:
the red, the eastern and western gray, and the antilopine.
There are also smaller tree-kangarus and rat-kangarus.
||||||| merged common ancestors
The kangaroo is probably the most widely known marsupial.
There are actually four species of large kangaroo:
the red, the eastern and western gray, and the antilopine.
There are also smaller tree-kangaroos and rat-kangaroos.
=======
The kangaroo is probably the most widely known marsupial.
There are actually four species of large kangaroo:
the red, the eastern and western grey, and the antilopine.
There are also smaller tree-kangaroos and rat-kangaroos.
>>>>>>> master
\begin{plate*}[h]
但是,这是默认行为.您可以通过命令行开关或.gitattributes文件更改默认值.
您选择了union合并,git文档有所改进:
union对文本文件运行3向文件级别合并,但从两个版本中获取行,而不是留下冲突标记.这往往会以随机顺序在结果文件中保留添加的行,用户应验证结果.如果您不理解其含义,请不要使用此功能.
(我的粗体).不过,这里的简短版本是git会相信合并成功(好吧,它确实成功了)但是会通过生成无效的XML文件来实现.在链接的haacked.com页面上有一些关于*.csproj文件出错的确切方法的例子,但这通常适用于任何联合合并:它不够聪明,无法获得正确的结果,而且很少有地方是合理的驱动程序.在某些情况下手动调用它会有一定意义,然后查看文件并手动进行任何修正,但由于它只是成功并让合并继续进行,所以你必须非常小心地将其放入.gitattributes.
理想情况下,我们希望有一个合并驱动程序,它可以理解XML格式和.csproj文件的意图(仅仅XML格式是不够的,因为标记的语义与语法无关).由于我不在Windows上使用VS,我只能再次引用haacked.com文章:
另一种方法是为Git编写一个合适的XML合并驱动程序,但这是一个相当大的挑战,因为我的同事Markus Olsson可以证明这一点.如果它很容易,甚至是中等难度,那就已经完成了.虽然我想知道我们是否将它限制为普通.csproj问题我们可以编写一个不完美但足以处理常见合并冲突的问题吗？也许.
如果内容像示例XML一样简单,我认为这样的驱动程序不会太难,所以我怀疑它们变得更复杂.