主分支和开发分支从未同步，甚至在 bitbucket 中遵循 git-flow 进程答案

【问题标题】：Master and develop branch never synced even follow git-flow process in bitbucket主分支和开发分支从未同步，甚至在 bitbucket 中遵循 git-flow 进程
【发布时间】：2020-06-15 22:07:11
【问题描述】：

我正在关注 git-flow 分支模型，并将我的存储库托管在 Bitbucket Cloud 上。

对feature 分支（从develop 分支）的贡献已通过 PR 合并到develop 分支中
需要发布时：
1. 从最新的develop 创建一个release 分支；
2. 合并master到release； （我必须按照后面的说明执行此步骤）
3. 增加版本号；
4. 通过 PR 将 release 合并到 master。
需要修补程序时：
1. 从最新的master 创建一个hotfix 分支；
2. 增加补丁版本号
3. 通过 PR 将 hotfix 合并到 master。
完成修补程序后：
1. 从最新的master 创建一个bugfix 分支；
2. 解决了很多冲突；
3. 通过 PR 将 bugfix 合并回 develop。

我一直严格遵守上述程序。但是，master 和 develop 永远不会同步，即使在发布之后，Bitbucket Cloud 分支页面上的指示器告诉我master 分支是“99 次提交后开发”和“11 次提交前开发”。

每次发布时，Bitbucket Cloud 总是告诉我两个分支不同步（即使我在上一个版本之后没有对master 分支进行任何更改），因此我必须执行步骤2上述发布程序。这一步变得越来越难，因为它会在合并过程中不断添加已从 develop 中删除的文件（也应该从 master 中删除）。

我不确定我做错了什么。有人可以推荐吗？

【问题讨论】：

所有合并都是真正的合并吗？只是检查....
@matt 我不确定是否存在虚假合并？我很少使用 git cli，我一直在使用 Soucetree GUI，最近切换到 Intellij 的 git GUI。我在尝试合并时所做的只是：签出一个分支，选择另一个分支并在 GUI 中单击“合并到当前”，然后使用 GUI 的交互式合并工具解决冲突。
但你不能为 PR 这样做，因为你不在电脑上。您在遥控器的 Web 界面上。它可能会提供虚假的合并。例如，由 github 提供的 squash and merge 不是合并。让我换一种说法：每次在故事中使用“合并”一词时，是否存在双父合并提交？
是的，完全正确。它不会给你一个“更干净”的提交历史；它为您提供 no 提交历史记录。分支保持独立。因此，正如您所说，您永远不会同步。
是的。挤压和合并对于一种无历史的前向迭代非常好，例如，develop 似乎通过智能有目的的迭代一步一步神奇地增长。如果您在功能分支上工作并将合并到develop 并强制删除功能分支，那么看起来develop 巧妙地进步了，没有人比这更聪明。但是对于真正的长寿命并行分支，例如develop 和master，如果“通过 PR 将release 合并到master”意味着“挤压合并”，则release 和master 只是在增长独立，这是一场灾难。

标签： git bitbucket git-flow

【解决方案1】：

正如@matt 在上面的 cmets 中指出的那样，develop 和 master 分支从不同步的根本原因是因为我一直在 Bitbucket PR 中使用“压缩和合并”。

我刚刚执行了一个发布 (develop -> release -> master)，使用“显式合并”（非快进）将发布 PR 合并到 master，现在是 develop 和master 分支是同步的。

对于不同的合并策略，即。 显式合并（非快进） vs 隐式合并（快进） vs 挤压合并，可以参考这篇文章@987654321 @ 用于对差异的高级讨论。我发现 GIF 很有帮助。

【讨论】：