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

Question

如果没有Project Y的更改，Project X如何发布（合并为Master）？

继续前进，解决方案A，B和C是否应该是单独的存储库（尽管它们在业务级别相关）？

方案

我们有一个包含以下内容的存储库：

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

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

Project X需要更改解决方案A和C.这些更改在功能分支中完成，合并回dev并持续部署到我们的Staging环境中。

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

Git History

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

- ＆GT; ProjectX - ＆gt; ProjectY

业务要求

业务不再希望Project X进入生产阶段，因为Y项目现在是优先级1＆＃39;。 没有可以释放项目X的更改。

分支策略

我们遵循以下策略：

发布策略

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

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

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

Answer 1

我看到你引用了标准的git flow＆＃39;分支策略，与http://nvie.com/posts/a-successful-git-branching-model/一起引入，在许多大型项目中以某种形式存在。

值得注意的是关于“发展”的文章。分支：

  

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

关于特征分支的段落：

  

功能分支的本质是，只要该功能处于开发状态，它就会存在，但最终会合并回开发（以便将新功能添加到即将发布的版本中）或丢弃（如果令人失望的话）实验）。

更改不应出现在＆＃39; develop＆＃39;分支，直到确认发布为止。如果您的Project X没有获得批准，那么它不应该出现在开发分支中，因此您只会释放项目Y.

所以，回答你的问题，

1）你可以cherry pick你的Project Y承诺申请掌握。我不建议这样做，因为主人应该是一个已知的稳定状态，你不会用Project Y测试环境而不是Project X来确认这个。相反，我会revert项目X从开发变更（留在功能分支中），重新测试然后合并开发成主。

小心地将Project X功能分支中的更改重新应用到develop中，因为它们仍然具有合并历史记录，重新应用它们变得非常简单 - 请参阅here以进行旧讨论。

2）我相信如果项目仍然跨越多个存储库，单独的存储库将无法帮助您。在一般实践中，你应该对你已经很好的结构。如果所描述的方案（已开发的功能的最后一分钟发布块）频繁发生，那么您的问题在于对发展变更的批准过程。具有不确定未来的特征应该在其特征分支中进行，直到确认发布。确认后退出更改的成本（时间和风险）必须向业务部门说明。

Answer 2

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

项目x将具有直接依赖性和c＆＃34; via＆＃34;一个。 项目y将b作为直接依赖，c＆＃34; via＆＃34;湾

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

ps：我知道这个答案不是真正的解决方案＆＃34;。但也许是一种＆＃34;确认＆＃34;你已经知道的。或者鼓励＆＃34;做你想做的事情。 ： - ）