VS 2013 C＃和Git：.csproj的文件不拉后合并 [英] VS 2013 C# and Git: .csproj files don't merge upon pulling

问题描述

我和一个朋友正在使用VS 2013 Express中的Git写在C＃项目（的不的在VS的Git插件，请注意），我们正在运行到一个问题。我们的工作流程的设置是这样的：我们有一个中央存储库，而我们每个人都有自己，我们就分头工作的库叉。当我们每一个人的工作完成后，我们推到中央存储库。当我们希望与中央存储库同步，我们拉。

Me and a friend are working on a project written in C# using VS 2013 Express with Git (not the VS Git Plugin, mind you), and we're running into a problem. Our workflow is setup like this: we have a central repository, and we each have our own fork of the repository that we work on separately. When our individual work is done we push to the central repository. When we want to sync with the central repository, we pull.

的问题是，当我们拉的的csproj文件随机更新。有时他们正确地更新和自上次拉已添加的文件在VS中正确显示，和其他时间的csproj文件是完全不受影响。

The problem is that when we pull, the csproj files randomly update. Sometimes they properly update and the files that have been added since the last pull properly show up in VS, and other times the csproj file is completely unaffected.

这很奇怪，因为得到的csproj正确更新其他地方，包括中央存储库，它只是有时不正常时，我们拉更新。

It's strange because the csproj gets updated properly everywhere else, including the central repository, it just sometimes doesn't update properly when we pull.

在我们的 .gitattributes 文件我们 .csproj的设置为合并=工会。

In our .gitattributes file we have .csproj set to merge=union.

我们拉扯时，执行的命令是 git的拉动上游，其中上游只是一个遥远指着我们的中央资料库。

The command we perform when pulling is git pull upstream where upstream is just a remote pointing to our central repository.

任何想法？

推荐答案

我'LL把这个作为一个答案的基础上的爱德华汤姆逊的评论，其中包含此链接的合并中的csproj文件（haacked.com/archive/2014/04/16/csproj-merge-conflicts）冲突。请注意，我一无所知视觉工作室，C＃或Windows，但我不知道混帐。 ： - ）

I'll put this in as an answer, based on Edward Thomson's comment, which contains this link to Merge conflicts in csproj files (haacked.com/archive/2014/04/16/csproj-merge-conflicts). Please note that I know nothing about Visual Studios, C#, or Windows, but I do know about git. :-)

的问题是，当我们拉的的csproj文件随机更新。有时他们正确地更新和自上次拉已添加的文件在VS中正确显示，和其他时间的csproj文件是完全不受影响。

The problem is that when we pull, the csproj files randomly update. Sometimes they properly update and the files that have been added since the last pull properly show up in VS, and other times the csproj file is completely unaffected.

首先，让我们做一些简短的复习笔记：

First, let's do a few brief review notes:

1. git的拉只是混帐取然后按 git的合并。你可以让Git做重订来代替。这可能是一个好主意，这取决于你的开发流程，但不会改变这个特殊的问题，因为...


2. 闲来无事在Git中，使合并的提交的但...


3. 若干其他命令，包括 git的重订，使用合并的设备的


4. 推（混帐推）的从不的做任何合并，所以你只看到问题给我新的东西都经过我和别人没有的东西的情况。即使这样，无论你看到的问题相当严重依赖于你和别人，别人做了什么。这是因为合并机械，由双方 git的合并中使用和 git的重订，是不那么聪明。

1. git pull is just git fetch followed by git merge. You can tell Git to do a rebase instead. This may be a good idea depending on your development flow, but won't change this particular problem, because ...
2. Nothing else in Git makes merge commits, but ...
3. Several other commands, including git rebase, use the merge machinery.
4. Pushing (git push) never does any merging, so you will only see the problem in the "get me new stuff after both I and someone else did something" case. Even then, whether you see the problem depends quite heavily on what you and the someone-else did. This is because the merge machinery, used by both git merge and git rebase, is just not that smart.

现在，让我们来看看下面的问题，这（基于链接）是这些。*的csproj 文件包含 XML ：那混帐的内置文本为导向的结构化数据合并操作的无法的正确合并。

Now let's take a look at the underlying problem, which (based on the link) is that these *.csproj files contain XML: structured data that git's built-in text-oriented merge operations cannot merge correctly.

更改冲突的时候，在 git的差异输出两种不同的开发线（分支机构或承诺被合并）发的不同的的修改一个文件的同一区域的。一个典型的例子，当两个编辑器无法拼写同意发生在文件中。例如，我前一段时间做这个改变：

Changes conflict when, in the git diff output, two different lines of development (the branches or commits being merged) made different changes to the same region of a single file. One classic example occurs in files when two editors cannot agree on spelling. For instance, I made this change some time ago:

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]

如果我是与别人谁做出了不同的改变任何的差异显示的线条，却留下灰色字母拼写合并本 A ，我会得到一个冲突。举例来说，如果我的编辑都坚持这个词拼写“ kangaru&rdquo ;,的变化会冲突：

If I were to merge this with someone else who made a different change to any of the lines shown in the diff, but left "grey" spelled with the letter a, I would get a conflict. For instance, if my editor were to insist that the word be spelled “kangaru”, the changes would conflict:

Auto-merging plates.tex
CONFLICT (content): Merge conflict in plates.tex
Automatic merge failed; fix conflicts and then commit the result.

当混帐遇到冲突的更改，其通常的反应是简单地宣布有冲突并停止它让你有一张树的版本包含文件冲突标记<<<<<<< ======= >>>>>>> 周围两侧冲突（与 ||||||| 基础版本上面一起的当且仅当的设置合并。 conflictstyle 到的diff3 ）：

When git encounters conflicting changes, its usual reaction is to simply declare that there is a conflict and stop. It leaves you with a work-tree version of the file containing conflict markers <<<<<<< ======= >>>>>>> surrounding both sides of the conflict (along with ||||||| above the base version if and only if you set merge.conflictstyle to 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 文件，更改默认值。

Again, though, this is the default behavior. You can, through command line switches or a .gitattributes file, change the default.

您选择了联盟合并和的 git的文件已经改善了一下：

工会

运行3路文件级合并为文本文件，而是采取从两个版本的线条，而不是让冲突标记。这往往会产生的文件中添加的行留在随机顺序和用户应当验证结果。如果你不理解的含义，不要使用它。

Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers. This tends to leave the added lines in the resulting file in random order and the user should verify the result. Do not use this if you do not understand the implications.

（粗体矿）。短的版本在这里，虽然是git会认为合并成功（当然，它的没有的成功），但将产生无效的XML文件，这样做。有确切的链接haacked.com页中的实例如何出错的 *的csproj 文件，但是这一般是真的任何联合合并：它不够聪明得到正确的结果，有几个地方是一个合理的驱动程序。它将使某种意义上手动调用它在某些情况下，然后查看文件，并进行手工任何的修正，但由于它只是成功，让合并进行，你必须非常小心把它放在 .gitattributes 。

(boldface mine). The short version here, though, is that git will believe the merge succeeded (well, it did succeed) but will do so by producing an invalid XML file. There are examples on the linked haacked.com page of exactly how this goes wrong for the *.csproj files, but this is generally true of any union merge: it's not smart enough to get the right result and there are few places where it is a reasonable driver. It would make some sense to invoke it manually in some cases, then review the file and make any fixups by hand, but since it just succeeds and lets the merge proceed, you must be very careful with putting it in .gitattributes.

在理想情况下，我们希望有一个理解的XML格式的和的的意图合并司机一个 .csproj的文件（单独的XML格式是不足以作为标记的语义不依赖于语法）。因为我没有在Windows上使用VS，我只能再次引述haacked.com文章：

Ideally, we would like to have a merge driver that understood XML formatting and the intent of a .csproj file (XML formatting alone is not sufficient as the semantics of the markup are not tied to the syntax). Since I do not use VS on Windows, I can only quote the haacked.com article again:

另一种方法是编写正确的XML合并驱动Git的，但是这是我的同事，马库斯·奥尔松可以证明相当大​​的挑战。如果是简单的，甚至是中等硬度，它会被已经完成。虽然我不知道如果我们把它局限于常见的.csproj问题可能我们写一个并不完美，但足以应付常见的合并冲突？也许吧。

Another way would be to write a proper XML merge driver for Git, but that’s quite a challenge as my co-worker Markus Olsson can attest to. If it were easy, or even moderately hard, it would have been done already. Though I wonder if we limited it to common .csproj issues could we write one that isn’t perfect but good enough to handle common merge conflicts? Perhaps.

如果内容是作为示例XML一样简单，我觉得这样的驱动程序是不是太困难，所以我怀疑他们变得更加复杂。

If the contents are as simple as the example XML, I think such a driver would be not too difficult, so I suspect they get more complicated.

这篇关于VS 2013 C＃和Git：.csproj的文件不拉后合并的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！