企业git分支战略的好模式？

Question

我刚刚创建了一个新的github，并上传了一个应用程序的代码库。默认情况下存在“主”分支。建立更多分支机构以支持CICD的常见和适当的方法是什么？

例如，这个回购应该有一个“开发”分支。我应该简单地将main中的-b签出为"develop“，然后按原样提交/推送吗？此外，这个回购应该有一个专门的分支为第一个版本。语义版本控制通常用于以下内容：

develop-major.minor.patch

对于开发版的第一个版本，这个问题将得到解决-1.0.0？对我来说，这似乎是一种合乎逻辑的方法，但企业git分支战略的领域不是我的专长领域。

Answer 1

我从事过许多企业级项目，我个人的偏好是始终遵循以下基本大纲：

• 主分支-总是匹配当前发布到生产
• 的发布分支- v2.0.0，例如，
• a构建分支- v2.0.0.1，或者如果您有许多正在执行的构建，则会执行v2.0.0.。
• 是一个特性分支- CR-123-SomeDescription，包含修补程序、新特性等

。

当功能/修复分支的工作完成时，它将合并到构建分支中。构建分支有目的地存在，以确保所有CI/CD构建过程、单元测试传递等都成功执行。如果单元测试通过成功，构建分支将合并到发布分支中并部署到暂存/测试服务器上。

发布分支是标记的，因此很容易识别，而不是像您建议的那样使用Develop-mainor.minor.修补程序命名分支。如果您确实遵循了这种模式，那么必须有人在某个时候清理这些分支，如果应用了大量的修补程序，它可能会花费大量时间。

首先将CI/CD构建推送到DEV实例，这样开发人员就可以使用应用程序遍历他的更改，运行附加集成测试等等。一旦DEV测试完成，相同的构建将被部署到测试环境中并移交给QA团队。

在QA给出一切都很好的祝福之后，它就会被部署到生产中，并且该发布分支被合并到主分支中。遵循这个概念，master总是反映当前的产品，因此如果您需要执行紧急修补程序，只需签出主程序、应用修补程序、添加一个新标记(例如v2.0.1.2)并将主版合并回当前发布分支。将主版合并回当前发布分支将迫使所有当前开发人员在这些更改被合并之前将其拉回原处，迫使您的开发人员与他们可能不知道的更改保持同步。

希望这能有所帮助。