VSTS和Git：为什么在与master合并时压缩我的DEV分支说DEV是落后于master还是领先于master？

Question

我希望有人可以帮助我，因为我正在摸不着头脑，了解发生了什么，以及是否可以纠正。

我目前正在开发VSTS项目并使用GIT作为代码库。我有一个通常的MASTER分支，有一个开发分支。然后，我在DEVELOPMENT分支之外创建功能分支。

当我们完成功能分支的更改后，我创建了一个Pull Request，并且可以成功地将更改合并到DEV分支中。然后DEV分支在MASTER之后显示“0”和“x”......这是正确的。

当我们准备将更改合并到MASTER时，问题就出现了。我们创建了一个PULL REQUEST来执行此操作，并且更改成功合并到MASTER中......但是...... DEV分支现在说它比MASTER落后1并且仍然领先于MASTER !!为什么DEV 1落后于MASTER？为什么DEV仍然领先于MASTER？在PULL REQUEST之后，MASTER和DEV不应该同步吗？也就是说，DEV应该落后0，比MASTER提前0？

我很有可能没有正确理解GIT，但是我可能在VSTS中有一些错误的设置......就像错误设置分支策略一样？我在MASTER上设置的唯一分支策略（在此阶段）是“实施合并策略 - 壁球合并”。

提前致谢。

Answer 1

壁球合并是造成误解的原因。

当你压缩合并时，你的开发分支的所有提交都被压缩成一个单独的提交。这就是为什么DEV落后于主人的原因，因为它没有被压缩的提交。 DEV也是master的x，因为DEV有x次提交，而不是master。

理想情况下，您应该只合并您的功能/主题分支，这将为您提供每个功能一次提交。合并到master时，不应该压缩dev分支。因此，您可以更改master上的分支策略，并在需要时将该策略放入DEV中。我的建议是让你的开发人员决定何时挤压。当您在VSTS中完成PR时，它会为您提供压缩选项。

Answer 2

只是为@ harshil-lodhi（绝对正确）答案增加一些可见性。

在创建拉取请求之前，存储库的状态如下所示：

如果您在SourceTree工具中查看此存储库，它会证明数字是正确的（后面有1个，前面有3个）：

当您合并强制提交压缩的拉取请求时，状态将更改为以下（VSTS）：

和SourceTree：

dev分支仍然有3个单独的提交，这就是为什么它比master提前3次提交。另一方面，master在合并/压缩期间还有一个提交，压缩从dev分支到达的变化。如你看到的。压扁的提交不是合并提交 - 它没有2个父母。尽管dev和master分支的内容相同，但它们仍然是Git的不同分支。

Answer 3

这是由VSTS处理快进合并的方式引起的。我们可以通过图表来说明细节。

在完成PR以将feature分支合并到dev之后，dev分支在mater分支后面为0并且前面是x（假设它在此处提交了3个提交）， master和dev的提交历史记录如下：

...---A----B       master
            \
             C---D---E   dev

然后在创建PR以将dev合并到master并完成合并之后，提交历史记录如下所示：

...---A----B-----------F   master
            \         /
             C---D---E  dev

这是因为VSTS处理与--no-ff选项（ git merge --no-ff ）的快进合并。

对于处理快进合并的默认方式（git merge dev），它会使master分支指向具有dev分支的相同提交（它们都将指向如上例所示提交E。

但是对于--no-ff merge（git merge --no-ff dev），git将创建一个新的合并提交，即使它是快进合并。

所以dev分支显示后面有1个提交（提交F），提前3个提交（提交C，D和E）与master分支比较。