如何使用我们的 Git 工作流解决合并策略冲突

Question

我在这里看到了很多类似的问题，但没有一个回答我们的具体问题。我的问题实际上是关于合并策略的，但我必须先描述我们的 git 流程。 我已经阅读了很多关于理想 Git 工作流的最佳实践，但我发现没有一个东西完全适合我们的需求。所以我们可能使用了一种不理想的方法。

流程如下：

我们有一个 ma​​ster 分支，与生产环境保持一致。我们有一个可发布分支，用于在预生产环境中使用真实数据测试发布包。我们有一个 stable 分支，用于在稳定的环境中进行测试。当我们开始开发新功能时，我们会从 ma​​ster 创建一个 feature 分支。功能完成后，我们通过 pull pequest 将其合并到 stable。这是问题所在；许多功能要么在测试完成后被取消，要么必须等待未来的发布，所以我们必须从 ma​​ster 分支出来，因为我们不希望这些功能出现在我们的新分支中。出于这个原因，我们也不能将 stable 与 releasable 合并。因此，如果该功能已准备好继续运行，我们将通过另一个拉取请求将 feature 分支合并到 releasable。现在，由于合并提交，stable 和 releasable 之间存在不同的提交。包准备好部署后，我们将 releasable 与 ma​​ster 合并。我的问题来了；当我们从 ma​​ster 创建一个新的 feature 分支以开始处理新功能时，它与 stable 的提交历史略有不同。由于这种差异，有时所有文件更改都会显示在 feature 分支和 stable 之间的差异中，即使它们的内容相同。

我们正在使用 Bitbucket。我已经考虑在拉取请求中使用 -ff 而不是 --no--ff ，但我也不想丢失合并提交。我也考虑过在 Bitbucket 中使用 Rebase, merge (rebase + merge --no-ff) 合并策略，但我不确定它是否能解决我们没有干净的 pull request 的问题。 p>

总而言之，我需要对 stable 有干净的拉取请求，只需要在该 feature 分支中完成更改，而不必牺牲太多。

任何帮助将不胜感激。

Answer 1

没有万能的 Git 分支策略，但有涵盖大多数场景的概括。它们往往属于以下类别之一：

1. 单个长寿命共享分支（通常为main 或master）。这可以进一步细分为 2 个子类别：A.) 基于主干的开发 (TBD)，其中开发人员都在 main 的本地副本上工作，以及 B.) 开发人员的所有分支都来自 main，并拥有自己的个人分支和合并回main。即使这样也有很多选择，例如变基然后快速合并，或者变基和--no-ff，或者根本没有变基，或者有/没有拉请求等，但总体包含的想法是每个人都可以工作的单个共享分支关闭。这在 CI/CD 类型交付中很受欢迎。
2. 至少有一个长期共享分支，以及一些短期一次性集成分支。这就是 Git 的维护者使用的，它被称为“Gitworkflows”。 这是我向您推荐的类别；更多详情如下。
3. 分离长期共享分支，以便在当前待定版本以及待定版本之后的下一个未来版本上同时开发。此类别是类似于“Git Flow”的策略风格。
4. 其他三者的某种组合。

请注意，您的问题与this one 非常相似，the answer there 几乎是我在您的情况下的建议，但需要稍作调整。主要区别在于，在您的情况下，您有 2 个长期存在的分支（master 和 releasable），您可能会受益于将您的 stable 分支设置为一次性分支，然后每隔一段时间重置为 master经常。 （如果您希望更紧密地与 Gitworkflows 保持一致，您也可以将 stable 重命名为 next。）我发现 1 或 2 周的重置频率通常适用于 next 分支。重置的次数越多越好，因为它更类似于合并到master 时会发生的情况。但是您不希望它经常让尚未完成测试的开发人员感到不安，然后必须重新合并到next 以在重置后继续测试。 一个可以解决您当前问题的可能重置频率是在您将releasable 合并到master 后立即将stable 重置为master。

旁注：在我的公司，我们在同一个 repo 中使用所有 3 类策略，具体取决于项目（因此我们属于第 4 类）。对于我们的 Git Flow 项目，我们还在沙盒开发环境中使用 next 作为“预测试”，以便在合并到 develop 之前实现不错的集成水平。我们为该项目每周重置一次next。