今天，我正在使用基于 Backbone.js 的开发风格的分支策略，由于不同的原因，从部署和协作的Angular 来看，这种策略并不是最佳的。我有一个想法，用其他东西来代替它，因为我们正在使用基于Azure的数据平台，该平台由几个不同的Azure产品（具有不同的代码量）组成。
为了支持CI/CD和灵活的协作，我不希望有发布分支，也不希望将开发类型的协作分支合并到主分支。
我的想法是让“master”分支与生产环境中运行的代码相对应，并创建一个（基本上永远存在）基于master的名为“development”的协作分支（或者可能是一个fork？）。然后对于正在进行的开发工作，开发人员将基于master创建一个特性分支，特性开发完成后，将与拉取请求合并到开发分支中，代码应部署到DEV/TEST环境中。特性测试完成后，相同的特征分支将与另一拉取请求合并到主分支中以部署到生产。
我可以看到这种分支策略的一个明显的缺点，那就是合并冲突必须解决两次，一次是在合并到开发分支时，另一次是在合并到master分支时。
这种类型的分支策略还有其他缺点吗？
1条答案
按热度按时间djmepvbi1#
一旦特性经过测试，相同的特性分支将与另一个拉取请求合并到主分支中，以便部署到生产中。
是的，完全正确！您不需要将集成分支合并到其他集成分支（如
dev、release、main等分支，其中您将多个特性分支集成在一起）。将 * 相同 * 的特性分支合并到不同的集成分支允许您精确地选择准备进入下一个交付阶段的特性。
集成分支是长期分支，您要将 * 合并到 ，而不是将 * 从 * 合并。
我以前将该过程描述为*gitworkflow**（一个词）
缺点是：你在一个分支中构建的并不是你在另一个分支中构建的，因为当你在一个集成分支中合并所述特性时，你并不总是选择合并在另一个集成分支中的特性分支的完整集合。
这意味着从一个集成构建的工件并不总是相同的。
但只要该构件仍然跨 * 所有 * 部署环境（开发/测试/预生产/生产）交付，这就不重要了。