VSTS 和 Git：为什么在将我的 DEV 分支 squash 到 master 时，会显示 DEV 分支既落后于 master，又领先于 master？

Question

希望有人能帮助我解决这个问题，因为我很费解发生了什么，并且是否可以纠正。

目前我正在使用GIT作为代码存储库，在VSTS上开展一个项目。 我有通常的主分支MASTER，并从它创建一个DEVELOPMENT分支。 然后我从DEVELOPMENT分支创建功能分支。

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

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

很有可能我没有正确理解GIT，但是我在VSTS中设置了一些错误的设置，例如错误地设置了分支策略吗？ 在MASTER上我唯一设置的分支策略（在这个阶段）是“强制执行合并策略 - Squash merge”。

提前感谢您的帮助。

- Dazfl

Answer 1

你的误解是因为使用了Squash merge。

当你使用Squash merge时，所有开发分支的提交将被压缩成一个单一的提交。这就是为什么DEV比master落后1个提交，因为它没有压缩的提交。同时，DEV比master领先x个提交，因为DEV有x个提交不在master中。

理想情况下，你应该只压缩合并你的特性/主题分支，这将给你每个特性一个提交。当你合并到master时，你不应该压缩你的dev分支。所以你可以改变master上的分支策略，并将该策略应用于DEV。我的建议是让你的开发人员自己决定何时压缩或不压缩。当你在VSTS中完成一个PR时，它会给你一个压缩的选项。

- Harshil Lodhi

---

完美...这个方法可行。谢谢你解释为什么会发生这种情况。很有道理。 - Dazfl

Answer 2

为了更加明确@harshil-lodhi的正确回答，以下进行补充。

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

如果你在SourceTree工具中查看此存储库，则可以证明数字是正确的（1个落后，3个领先）：

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

以及SourceTree：

开发分支仍然有其3个单独的提交，这就是为什么它比主分支多3个提交。另一方面，主分支有一个更多的提交，即从合并/压缩期间来自开发分支的压缩更改。如你所见，压缩提交不是合并提交-它没有2个父级。尽管开发和主分支的内容相同，但对于Git来说仍然是不同的分支。

- Yan Sklyarenko

Answer 3

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

完成将feature分支合并到dev后，dev分支与master分支相比，落后0个提交，领先x个提交（假设这里领先3个提交），master和dev的提交历史如下：

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

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

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

那是因为VSTS使用--no-ff选项(git merge --no-ff)来处理快进合并。

对于默认的方式(git merge dev)处理快进合并，它会让master分支指向与dev分支相同的提交(如上例，它们都将指向提交E)。

但对于--no-ff合并(git merge --no-ff dev)，即使它是快进合并，Git也会创建一个新的合并提交。

所以dev分支显示它比master分支落后1个提交(提交F)，并领先3个提交(提交C、D和E)。

- Marina Liu