VSTS 和 Git：为什么在合并到 master 时压缩我的 DEV 分支会说 DEV 既落后又领先于 master？答案

【问题标题】：VSTS and Git: Why does squashing my DEV branch while merging to master says that DEV is both behind and ahead of master?VSTS 和 Git：为什么在合并到 master 时压缩我的 DEV 分支会说 DEV 既落后又领先于 master？
【发布时间】：2018-07-29 10:50:34
【问题描述】：

我希望有人可以帮助我解决这个问题，因为我正在摸索以了解发生了什么，以及是否可以纠正。

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

当我们完成特性分支中的更改后，我创建了一个拉取请求，并且可以成功地将更改合并到 DEV 分支中。然后 DEV 分支在 MASTER 后面显示“0”，在 MASTER 前面显示“x”……这是正确的。

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

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

提前致谢。

【问题讨论】：

标签： git azure-devops branching-and-merging

【解决方案1】：

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

当您压缩合并时，您的开发分支的所有提交都被压缩为一个单独的提交。这就是 DEV 落后于 master 1 的原因，因为它没有压缩提交。 DEV 也比 master 领先 x，因为 DEV 有 x 次提交，这些提交不在 master 中。

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

【讨论】：

完美……这行得通。感谢您解释为什么会这样。很有道理。

【解决方案2】：

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

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

如果您查看 SourceTree 工具中的这个存储库，它证明数字是正确的（1 落后，3 领先）：

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

和源树：

dev 分支仍然有 3 个单独的提交，这就是为什么它在 master 之前有 3 个提交。另一方面，master 还有一个提交，在合并/压缩期间从 dev 分支到达的压缩更改。如你看到的。压扁的提交不是合并提交 - 它没有 2 个父级。虽然 dev 和 master 分支的内容是一样的，但是对于 Git 来说还是不同的分支。

【讨论】：

【解决方案3】：

这是由 VSTS 处理快进合并的方式造成的。我们可以用图表来说明细节。

在完成 PR 将 feature 分支合并到 dev 后，dev 分支落后 0，mater 分支提前 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 合并（git merge --no-ff dev），即使是快进合并，git 也会创建一个新的合并提交。

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

【讨论】：