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来说还是不同的分支。