0

没有项目 Y 的更改，如何发布项目 X（合并到主控）？

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

设想

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

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

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

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

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

Git 历史

此时，我们的 Git 历史看起来像这样（从最早到最新）：

--> 项目X --> 项目Y

业务需求

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

分支策略

我们遵循以下策略： 在此处输入图像描述

发布策略

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

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

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

4

2 回答 2

2

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

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

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

以及关于特征分支的段落：

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

在确认发布之前，更改不应出现在“开发”分支中。如果您的项目 X 没有获得发布的批准，它不应该出现在开发分支中，因此您只发布项目 Y 没有问题。

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

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

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

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

于 2016-05-10T16:48:19.793 回答
1

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

项目 x 将具有 as 直接依赖项和 c“通过”a。项目 y 将 b 作为直接依赖项，c “通过” b。

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

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

于 2016-05-09T14:34:31.680 回答