解决Git（Team Foundation Server）悖论

这怎么可能呢

这两个分支明显不同，但公关部表示，他们找不到任何区别

我被难住了。然后被封锁了。在我将代码放入dev之前，我无法继续，所以这不仅仅是好奇

我甚至尝试将MarketResearch 2合并到dev中。它告诉我它已经是最新的了

然而，我可以在VisualStudio中来回切换它们，并看到它们之间的差异

合并并不是你认为它的意思 问题很简单：merge（作为动词，即作为要采取的行动）并不意味着“完全相同”。它的意思是“结合变化”

让我们后退一分钟。我们所说的“变化”到底是什么意思？提交中有什么内容？以及：

你提到：

我可以在他们之间来回切换。。。看看。。。分歧

让我们先弄清楚“他们”是什么意思。请参见关于“分支机构”的链接问题，但根据您的图片，“它们”是名称

marketresearchavement2

和

dev

。这两个名称实际上转化为两个特定的提交ID：两个丑陋的SHA-1散列，IDE将它们隐藏起来（cough:-），这样您就看不到它们了，但实际上它们看起来像

7b19d86e69d…

或类似的东西

这些散列ID隐藏在名称后面，因为散列ID对人类来说真的不是很有用，它们表示特定的提交。每个提交都有自己唯一的散列ID。但提交到底是什么

当您在这两个提交之间来回切换时，您会看到一个完整的文件树：一个工作树的快照。这是提交的一部分。提交使您能够访问工作树的快照：您可以签出任何历史提交并检索与该提交一起保存的工作树

提交的其余部分是一组元数据，包括进行提交的人和日志消息，以及对Git父提交非常重要的内容，即在进行特定提交之前的提交

家长及分行 大多数提交都有一个父级。这些父母以一种倒退的方式形成了项目的历史或项目的某些部分。这使我们（和Git）可以从最近的提交开始，并向后工作：

... <- o <- o <- o   <-- dev

这让我更容易画树枝。现在

dev

指向最近的

dev

commit，而

ziggy

指向最近的

ziggy

commit。名称

dev

和

ziggy

指向一个特定的提交，而那些提交指向较旧的提交

请注意，我用

*

标记了一个提交，其中两组向后连接的箭头连接在一起。这是理解合并的关键项目之一

比较提交 在两个特定提交之间来回切换时，会看到不同的文件。Git可以为您比较这两个提交。在命令行中，您只需运行：

git diff dev MarketResearchCampaign2

比较这两个提交。您的IDE也应该有这样做的方法

不过，更常见的情况是，您可能不希望比较两个不同的分支名称，而是比较某个分支上某个地方的提交与其父提交之一。也就是说，考虑到上面类似于

dev

和

ziggy

的内容，我们可以将

dev

的提示与

dev

的提示返回的提交一个进行比较：提交之后的两个提交

*

。这将向您显示在进行这两次提交中的第二次提交时所做的更改

我们还可以将这两种方法中的第一种与commit

*

本身进行比较。这将显示从

*

到这两个提交中的第一个提交所做的更改

当然，我们可以将

*

与

dev

的技巧进行比较。这将向您展示从

*

到

dev

的所有提交中所做的一切

同时，我们可以用同样的方式将

ziggy

的提示与以前的提交进行比较。如果我们将

ziggy

上的最后一次提交与它的前一次提交进行比较，就可以看出我们在那里做了什么。如果我们将

ziggy

上的最后一次提交与提交

*

进行比较，那么：好吧，与提交

*

相比，这显示了我们在分支

ziggy

上所做的一切

但是看看commit

*

在哪里 commit

*

的有趣之处在于，它位于两个分支上：这是最近的一次commit，其中

dev

和

ziggy

仍然在一起。从那时起，

dev

出现了分歧，出现了几个新的提交；Zigy也出现了分歧，出现了几个新的提交。如果我们认为这是一个好主意，我们现在可以重新加入这两行：我们可以让Git在

dev

中找到“自

*

以来我们所做的一切”，在

Zigy

中找到“自

*

以来我们所做的一切”，并做出一个新的提交，将这两行重新组合

这就是merge所做的：它查找自某个公共点以来的更改

请注意，提交之前的任何提交

*

也在两个分支上。使

*

在这里特别的不仅仅是它在两个分支上，而是它是两个分支上最近的提交。1

---

1从技术上讲，它是DAG或有向无环图中的“最低共同祖先”或LCA。只有当存在多个LCA时，这种技术性才起作用。一个或另一个LCA实际上可能较新，但实际上重要的是拓扑结构，而不是日期。Git和其他一些VCSE处理多重LCA案例的方式与Mercurial不同。在这种情况下，Git实际上为您提供了一种合并策略的选择：

-s recursive

做一件事，

-s resolve

做另一件事。但这是一个单独的高级主题

---

合并生成新的公共提交点 <

git diff dev MarketResearchCampaign2

...--o--o--o   <-- dev
      \     \
       o--o--M   <-- ziggy

...--o--o--*   <-- dev
      \     \
       o--o--M--o--o--o   <-- ziggy

...--o--o--*   <-- dev
      \     \
       o--o--M--o--o--o   <-- ziggy

...--o--o--o------------N   <-- dev
      \     \          /
       o--o--M--o--o--o   <-- ziggy

...--o--o--o
      \     \
       o--o--M--o--o--*   <-- dev, ziggy

...--o--o--o            o   <-- dev
      \     \          /
       o--o--M--o--o--*--o--o   <-- ziggy

...--o--o--o------------N--o   <-- dev
      \     \          /
       o--o--M--o--o--o--o--o   <-- ziggy