CICD的Git分支策略

Question

只是在下面的分支策略上寻找思路，记住CICD。

1. 主支部- 1.1拓展处 团队A分支-从开发分支到开发分支，在QA/Integration分支的特性实现之后合并到开发分支--与上面的1.1.1发布分支相同-进入PROD

一旦团队A和B分支合并和QA验证完成，创建发布分支并对其进行最终回归。这个发行部门将投入生产。

然后将发布合并到主分支。

意图-

1. 主分支是稳定的，生产运行代码是可用的。
2. 团队分支可以部署在DEV环境上，并且需要在服务器上进行CICD配置。

这种方法有什么问题吗？

Answer 1

要真正做CI (并且CI需要做CD)，您将合并为非常有规律的掌握，并且没有长期存在的特性分支。我相信，一天一次，它将是"CI“。

与您建议的方法相比，另一种方法是让短期的开发人员分支进行日常工作。然后有一个部署管道，将每个代码更改移动到一系列测试阶段。只有在每一阶段的变化都过去之后，它们才会进入下一阶段，并准备好投入生产。这允许您在主服务器上工作，但可以保持稳定，并且只允许传递代码进入生产。

要处理独立的特性工作，您可以使用功能切换而不是分支。您可以切换功能，并推送到主测试和部署，如果一切顺利的话。如果没有，或者如果有业务需要删除某个特性，您可以关闭该特性并继续安全地使用master。我在两种产品上都很好地看到了这方面的工作。

我知道这是非常简单的，但它只是为你提出一个替代方案，希望能有所帮助。您可以在一堆博客和堆栈溢出答案( http://martinfowler.com/articles/feature-toggles - http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf - Feature Toggles vs Feature Branches )上了解有关实现这些技术的更多信息。

Answer 2

这不是真正的CI ( CI指的是开发策略，而不是工具)，因为您有团队分支，这意味着团队的工作在合并到主团队之前是不会集成的--总有一些团队的工作对其他团队不可见，并且看不到来自其他团队的工作(因此向打开重新基地/合并地狱)。

对于真正的CI策略，所有的团队都会在master上工作(如果真的把任务分支拉回来，他们很快就会被合并回掌握，不超过几天的寿命)--几乎每个人都在同一个页面上。

CI工具(或者是分期环境中的CD工具)可以监视master的健康状况。

每当master是current release-ready，或者当对next release的更改开始与current release (发布发散)发生冲突时，current_release分支就会被拉出来，永远不会被合并回主服务器中(这种合并将是一个大问题，因为发布发散)。current_release中的任何bug修复(如果同样适用于master )都是经过精心挑选和双重提交的(仅仅因为一个修复在一个分支上是OK的，这并不意味着它在另一个分支上是可以的)。

current_release分公司实际上就是您的生产分公司。它需要自己的CI/CD设置，根据current release特性量身定做。生产生成只是这个分支上的标签。

master分支继续向next release发展。

冲洗并重复。

您还可以为多个级别的发行版( back /minor/etc)提供current_release的更多子分支，这也是从不将合并回其父分支中。每个子分支与其父分支之间的关系与current_release和master之间的关系完全相同。