Git 分支策略以适应不断变化的功能优先级

Question

如何在没有项目 Y 的更改的情况下发布项目 X（合并到 Master）？

展望未来，解决方案 A、B 和 C 是否都应该是未来的独立存储库（尽管它们在业务层面相关）？

场景

我们有一个单一的存储库，其中包含：

• 解决方案 A
• 解决方案 B
• 解决方案 C（共享组件）

解决方案 A 和 B 都是我们整个系统的“插件”，通过通用组件将它们连接在一起。解决方案 A 和 B 依赖于解决方案 C 中的共享组件。

项目 X 需要对解决方案 A 和 C 进行更改。这些更改在功能分支中完成，合并回 dev 并持续部署到我们的暂存环境中。

项目 Y 只需要对解决方案 B 进行更改。再次在功能分支中，合并回 dev 并持续部署到 Staging。

Git 历史

此时，我们的 Git 历史记录如下所示（从最早到最新）：

--> ProjectX --> ProjectY

业务需求

企业不再希望项目 X 投入生产，因为项目 Y 现在是“优先级 1”。 没有可以发布来自 Project X 的更改。

分支策略

我们遵循以下策略：

发布策略

我们部署完整的产品包，而不是差异化。

在合并到 Dev 时，Team Foundation Server 会部署到 Staging。

在合并到 Master 时，Team Foundation Server 为每个构建定义提供一个格式化的部署包。

Answer 1

我看到您引用了标准的“git flow”分支策略，正如 http://nvie.com/posts/a-successful-git-branching-model/ 引入的那样，并且在许多大型项目中以某种形式存在。

值得注意的是关于“开发”分支的段落：

[开发分支]始终反映下一个版本的最新交付开发更改的状态

以及关于特性分支的文章：

特性分支的本质是，只要特性处于开发阶段，它就存在，但最终会被合并回开发中（以明确将新特性添加到即将发布的版本中）或丢弃（以防令人失望）实验）。

在确认发布之前，更改不应出现在“开发”分支中。如果您的项目 X 尚未获得发布许可，则它不应该出现在开发分支中，因此您只发布项目 Y 不会有任何问题。

所以，在回答您的问题时，

1) 你可以 cherry pick 你的 Project Y 提交申请到 master。我不建议这样做，因为 master 应该是一个已知的稳定状态，并且您不会使用 Project Y 而不是 Project X 在其中测试环境来确认这一点。相反，我会 revert 将 Project X 从 develop 更改（将它们留在功能分支中），重新测试，然后将 develop 合并到 master。

小心将 Project X 功能分支中的更改重新应用到开发中，因为它们仍然具有合并历史记录，并且重新应用它们变得非常重要 - 请参阅 here 了解旧讨论。

2) 如果项目仍然跨越多个存储库，我相信单独的存储库对您没有帮助。在一般实践中，您应该对已有的结构没问题。如果所描述的场景（已经在开发中的功能的最后一分钟发布块）经常发生，那么您的问题是与开发中更改的审批流程有关。未来不确定的功能应在其功能分支中上演，直到确认发布。必须向企业明确说明在确认更改后撤销更改的成本（时间和风险）。

Answer 2

在我看来，您应该将 a、b 和 c 分成三个单独的存储库/项目。 a 和 b 应该引用 c 作为依赖项。

项目 x 将具有 a as 直接依赖关系和 c "via" a。 项目 y 将 b 作为直接依赖项，c "via" b。

您可以继续为项目 y 和解决方案 b 开发新功能，而不会对项目 x 产生任何影响。除非您对解决方案 c 进行更改，这可能会更改解决方案 a 和/或解决方案 b 的 impl。

ps：我知道这个答案不是真正的“解决方案”。但也许是一种你已经知道的“确认”。或“鼓励”去做你曾经想改变的事情。 :-)