「研发部」GitFlow规范-升级版（二）

本文主要是介绍「研发部」GitFlow规范-升级版（二），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

上一篇文章简单整理过一次产研团队的GitFlow《Git 分支管理及Code Review 流程 (一)》

GitFlow是一种流行的Git分支管理策略，它提供了一种结构化的方式来管理项目的开发和发布流程。以下是GitFlow规范的主要组成部分：

主要分支：

• master：主分支，存储的是正式环境的代码，它是稳定并且可部署到生产环境的。此分支应该是只读的，不允许直接在上面进行开发。
• develop：开发分支，所有新的功能开发都应该基于这个分支。它是master分支的副本，并且是集成测试的场所。

辅助分支：

• feature：功能分支，用于开发新功能。每个功能都应该有一个自己的分支，它的命名规则可以是feature/*，比如feature/new-login。当功能开发完成并通过测试后，它会合并到develop分支。
• release：预发布分支，用于准备新的生产版本。它基于develop分支创建，并且用于修复在预发布阶段发现的问题。它的命名规则可以是release/*，比如release/1.2.0。当预发布阶段结束后，它会合并到master和develop分支。
• hotfix：热修复分支，用于修复生产环境中的紧急问题。它基于master分支创建，并且当问题修复后，它会合并到master和develop分支。它的命名规则可以是hotfix/*，比如hotfix/1.2.1。

工作流程：

• 当开始一个新功能时，从develop分支创建一个新的feature分支。
• 在feature分支上开发新功能，并通过单元测试。
• 完成后，将feature分支合并到develop分支，并删除feature分支。
• 当准备发布新版本时，从develop分支创建一个新的release分支。
• 在release分支上进行集成测试，并修复发现的问题。
• 完成后，将release分支合并到master和develop分支，并删除release分支。
• 如果在生产环境中发现紧急问题，从master分支创建一个新的hotfix分支。
• 在hotfix分支上修复问题，并通过测试。
• 完成后，将hotfix分支合并到master和develop分支，并删除hotfix分支。

以上就是GitFlow规范的基本内容。这种策略通过明确每个分支的角色和生命周期，以及定义清晰的工作流程，有助于保持代码的整洁和可维护性，提高团队之间的协作效率。

结合以上&目前的产研团队的GitFlow规范进行整理

1、产研开发规范

1.1 规范目标

• 确保业务需求所有上生产的代码均为测试过的代码
• 确保上线分支代码不被遗漏
• 开发流程规范化，合理化，便于管理

1.2 产研开发流程

如上图：

• 虚线上方为开发流程，虚线下方为每个流程需要的产出，色块的不同代表负责人为对应的角色
• 角色分为组长、产品、主R、开发、测试，分别用不同的色块代表

重要阶段必要参与人：

• 需求评审：产品、主R、开发、测试，负责角色为产品
• 设计评审：产品、组长、主R、开发、测试，负责角色为开发
• 用例评审：测试、产品、开发，负责角色为测试
• 冒烟：开发、测试、产品（建议），负责角色为开发
• 值班观察：负责角色为主R，可安排对应开发值班

2、Git分支规范

2.1 测试分支

• 【强制】命名：test-上线日期，示例：test-20221206
• 【强制】由项目主R建立，并建立分支保护，保护规则：必须经过Code Review
• 【强制】不允许直接推送代码至测试分支，必须通过合并，如产生冲突，在开发分支解决后再合并

2.2 开发分支

• 【强制】命名：feature-JIRA编号，示例：feature-JIRA001，feature-OFFICE001
• 【强制】由开发从 master 分支拉取创建

2.3 热修复分支

• 【强制】命名：hotfix-JIRA编号，示例：hotfix-JIRA001
• 【强制】必须从 master 分支拉取

2.4 master分支

• 【强制】分支保护模式，必须通过Code Review 合并

3、效能平台使用规范

3.1 环境发布分支规范

3.1.1 现状

• prod环境：取master / tag版本分值进行上线
• release环境：取master / tag版本分值进行发布
• uat环境：只能发布 hotfix*、master 分支
• test环境：只能发布 master、dev* 分支
• dev环境：只能发布 master、dev* 分支

3.1.2 修改

• prod环境：只能发布master/tag版本分支封板代码
• release环境：取master / tag版本分值进行发布
• uat环境：只能发布hotfix*、master分支 ，临时支持test*分支
• test环境：只能发布master、test*、hotfix*分支
• dev环境：不限制

3.2 环境使用规范

• dev环境：开发，团队开发同学统一使用。
• test环境：测试，开发完统一合并该环境供测试团队同学进行冒烟测试。
• uat环境：开发，预其他团队一对一环境，涉及到外部门合作的统一在该环境进行回归测试。
• release环境：上线前的预生产环境，数据使用的跟生产数据一致，用真实数据进行测试的环境。
• prod环境：生产环境，正式外部访问

3.3 遇到问题

• 测试分支稳定性相对不高，如单独弄测试分支流程会比较复杂
• 需要多套环境支持，可合并测试分支后一起测试
• git项目权限问题，需要运维给组长、可以针对主R开通相关权限

4、总结

对比其他版本管理工具，GitFlow有哪些优势？

GitFlow是一种Git分支管理策略，它与其他版本管理工具相比具有以下优势：

• 清晰的分工合作：GitFlow将开发过程分解为不同的分支，每个分支都有明确的职责，比如特性开发、发布准备和维护。这有助于团队成员之间更好地协作，避免代码冲突和混乱。
• 稳定的发布流程：通过特定的分支（如Release和Master分支），GitFlow确保了每次发布都是经过测试和稳定的版本。这有助于提供高质量的软件，并减少生产环境中的问题。
• 灵活的热修复：当生产环境中出现紧急问题时，GitFlow的Hotfix分支允许开发团队快速修复问题并发布，而不影响其他功能的开发。这有助于减少停机时间和维护成本。
• 高效的版本管理：GitFlow让版本追踪更加明确，团队可以清楚地知道每个版本的功能和改动。这有助于回滚到以前的版本或比较不同版本之间的差异。
• 强大的分支模型：GitFlow的分支模型非常灵活，支持多个并行开发流程，包括新功能开发、发布准备和修复生产问题等。这有助于提高开发效率和响应速度。
• 广泛的适用性：GitFlow不仅适用于有计划发布周期的项目，还可以用于持续交付的DevOps最佳实践。这使得GitFlow成为各种规模和类型项目的理想选择。

需要注意的是，虽然GitFlow具有许多优势，但它并不是唯一正确的版本管理策略。在选择版本管理工具和方法时，团队应根据项目的具体需求和团队的工作方式做出决策。

这篇关于「研发部」GitFlow规范-升级版（二）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---