一、为什么需要企业级开发模型？
一个软件从零开始到最终交付，大致需要经历：规划 → 编码 → 构建 → 测试 → 发布 → 部署 → 维护。在个人项目中，你一个人可以完成所有环节。但在企业中，角色分工明确：
-
开发团队（Dev）：追求快速迭代，不断加入新功能。
-
运维团队（Ops） ：追求系统稳定，不希望频繁变更。
这两个团队的目标有时是冲突的。为了弥合这个鸿沟，DevOps 文化应运而生。它通过自动化工具和标准化流程，让开发、测试、部署高效协作。而Git分支模型，正是DevOps中代码管理的核心一环。
简单来说，企业级开发模型要解决以下问题：
-
如何让多人并行开发不同功能，互不干扰？
-
如何保证主分支（master）的代码始终是稳定可发布的？
-
如何让测试人员在独立的环境中进行验证？
-
如何紧急修复线上问题，同时不影响正在开发的功能？
二、理解系统开发环境
先了解企业中的四大环境。每个环境对应不同的目的和分支。
| 环境名称 | 英文 | 作用 | 对应分支（常见） |
|---|---|---|---|
| 开发环境 | Development | 开发人员自己调试代码的地方，打开全部错误报告 | feature/* 或 develop |
| 测试环境 | Testing | 测试人员进行功能测试，模拟用户场景 | release/* |
| 预发布环境 | Staging/Pre-release | 与生产环境配置一致，上线前的最后一道关卡 | release/* |
| 生产环境 | Production | 正式对外服务的线上环境 | master |
这几个环境也可以说是系统开发的三个重要阶段：开发 -> 测试 -> 上线
2.1 开发环境
这是你每天编码的地方。你可以随意修改、提交、甚至推翻重来。通常，每个功能分支部署到独立的开发环境，或者所有开发人员共用一套开发环境（部署develop分支）。
2.2 测试环境
当某个功能开发完成后，会被合并到一个专门的测试分支 （如release），然后部署到测试环境。测试人员在这里执行测试用例，发现bug后反馈给开发人员修复。测试不通过，代码不能上线。
2.3 预发布环境
这是最容易忽视但非常重要的环境。它的硬件配置、数据库、中间件等与生产环境几乎一致。在上线前，将代码部署到预发布环境做最后的验证，可以避免因环境差异导致的线上问题。预发布环境是你的最后一道防线。
2.4 生产环境
就是用户真正使用的线上系统。只有经过完整测试和预发布验证的代码，才能部署到生产环境。生产环境上的代码必须绝对稳定，通常只有master分支会被部署到这里。
对于规模较大的公司，还会有仿真环境、灰度环境等，但万变不离其宗。
三、Git分支设计规范
基于上述环境，业界总结出了一套经典的分支模型------Git Flow。下面介绍五种核心分支。
1. master 分支（生产环境）
-
唯一且只读：master分支是代码库的稳定版本，任何时候都应该是可发布的。
-
只合并，不直接修改：不允许直接在master上提交代码。只能从release或hotfix分支合并进来。
-
打标签 ：每次合并到master并上线后，都要打一个标签（如v1.0.0），方便回滚。
2. develop 分支（开发环境）
-
日常开发集散地 ：develop分支是开发的主线，包含了所有已经完成并测试通过的功能。
-
只读且唯一：通常也不允许直接提交，而是通过feature分支合并进来。
-
可部署到开发环境：开发人员可以随时将develop部署到开发环境进行联调。
3. feature 分支（功能开发）
-
来源于develop ：每开发一个新功能，就从develop创建一个feature分支，命名如
feature/user_20231012_order。 -
开发完成后合并回develop：功能开发完毕并自测通过后，提交Pull Request，经过代码评审后合并到develop。
-
临时分支：合并后即可删除。
4. release 分支（预发布/测试）
-
来源于develop ：当develop积累了足够的功能，准备发布一个版本时，从develop创建一个release分支，命名如
release/v1.0_20231012。 -
用于测试和预发布：release分支会部署到测试环境和预发布环境。测试人员在这里发现bug，开发人员直接在release分支上修复。
-
最终合并到master和develop：测试通过后，将release合并到master（并打标签），同时也合并回develop（确保develop也有bug修复）。
-
临时分支：发布完成后删除。
5. hotfix 分支（紧急修复）
-
来源于master ：当线上出现严重bug，需要立即修复时，从master创建一个hotfix分支，命名如
hotfix/user_20231012_critical。 -
修复后合并到master和develop：修复完成后，合并到master（打新标签），同时也必须合并到develop（或当前release分支），避免后续版本再次出现该bug。
-
临时分支：修复上线后删除。
|---------|--------|----------|
| 分支 | 名称 | 适用环境 |
| master | 主分支 | 生成环境 |
| release | 预发布分支 | 预发布/测试环境 |
| develop | 开发分支 | 开发环境 |
| frature | 需求开发分支 | 本地 |
| hotfix | 紧急修复分支 | 本地 |
-
feature 从
develop拉出，合并回develop。 -
release 从
develop拉出，合并到master和develop。 -
hotfix 从
master拉出，合并到master和develop。
实际团队中，可能还会有一个
pre-release分支，但原理类似。
- 其实，上面说的是企业级常用的一种Git分支设计规范 ：Git Flow模型，但是，这个模型并不是使用于所有的团队、所有的环境和所有的文化。
- 如果你采用了持续交付，你会想要一些能够尽可能的简化交付过程的东西；有些人喜欢基于主干的开发模式，喜欢使用特性的标志，然后，从测试的角度来看，完全不适用
四、企业级项目管理实战（基于Gitee企业版）
用Gitee企业版来模拟一个真实项目的完整生命周期。Gitee企业版免费提供了项目管理和协作功能，非常适合中小企业。
点击右上角"企业版"，选择免费版即可创建企业。填写企业名称（随意），如"我的测试企业"。
在企业工作台，点击"项目" -> "新建项目"。填写项目名称、描述，项目类型选择"普通项目"。项目创建后，你就可以在项目中管理多个仓库、任务、文档等。
在项目中，点击"代码" -> "新建仓库"。选择仓库类型为"Git"，初始化时可选择Git Flow分支模型（自动创建master和develop分支）。勾选"生成.gitignore"和"开源许可证"等。点击"创建"。
添加成员
多人协作需要将团队成员加入企业并赋予权限。
添加企业成员：在企业管理后台，点击"成员" -> "添加成员"，可以通过链接邀请或直接添加。被邀请者同意后成为企业成员。
添加项目成员：进入项目，点击"成员" -> "添加项目成员"，选择企业成员，并赋予角色（如开发者、测试者、管理者）。
设置仓库权限：进入仓库，点击"设置" -> "仓库成员"，可以给指定成员"管理员"、"写"、"读"等权限。
注意：开发人员至少要有"写"权限才能推送代码。
申请后需要负责人审批通过。
