Git 开发分支模型与 Git Flow 详解
引言
在实际的开发、运维及测试工作中，项目推进需要清晰的布局。不同的角色使用不同的分支，这涉及到多种开发模型。本文主要介绍 Git 中常用的分支模型及相关知识。
环境划分
开发环境通常分为以下四类：
- 开发环境：供开发人员日常编码使用。
- 测试环境：供测试人员进行功能验证。
- 预发布环境：模拟生产环境，进行上线前的最后检查。
- 生产环境：面对用户的线上服务平台。
核心分支定义
在 Git 工作流中，常见的分支包括以下几种：
Master 分支
- 用途：主分支，用于部署到正式发布环境。
- 规范：只读且唯一，任何情况下不允许直接在 master 上修改代码。产品功能全部实现后，最终在此分支对外发布。推送应打标签（tag）做记录。不可删除。
Release 分支
- 用途：预发布分支，基于 develop 分支创建，用于提交给测试人员进行功能测试。
- 规范：命名以
release/开头，如release/version_publishtime。属于临时分支，产品上线后可选删除。
Develop 分支
- 用途：开发分支，基于 master 分支创建，始终保持最新完成以及 bug 修复后的代码。
- 规范：可部署到开发环境对应集群。新功能通常由 feature 分支合并至此，不建议直接在上面开发。
Feature 分支
- 用途：新功能或新特性开发分支，以 develop 分支为基础创建。
- 规范：命名以
feature/开头，如feature/user_creatime_feature。开发完成后需合并到 develop 分支，需求发布上线后删除。
Hotfix 分支
- 用途：线上 bug 修复分支，用于对线上的版本进行紧急修复。
- 规范：基于 master 分支创建，命名以
hotfix/开头。修复完成后需合并到 master 和 develop 分支并推送远程，修复上线后删除。
Git Flow 模型
Git Flow 是一种非常有代表性的持续交付模型，隔一段时间发布一个新版本。企业级开发流程通常遵循此模型，通过不同分支的流转来平衡开发敏捷度与代码稳定性。
基本流程如下：
- 基于 develop 分支创建 feature 分支进行开发。
- 开发完成后请求代码评审，合并回 develop 分支。
- 基于 develop 分支新建 release 分支进行测试。
- 测试通过后合并至 master 分支并发布。
- 线上出现紧急问题时，基于 master 创建 hotfix 分支修复。
结语
实际中的开发工作远比理论描述复杂，但掌握上述分支模型是构建高效协作流程的基础。开发者应根据团队需求选择合适的分支策略。
