目录
引入
系统开发环境
Git 分支设计规范
master 分支
release 分支
develop 分支
feature 分支
hotfix 分支
开发场景 - 基于git flow模型的实践
DevOps研发平台
修复测试环境 Bug
修改预发布环境 Bug
修改正式环境 Bug
紧急修复正式环境 Bug
拓展实践
都说：对于开发者，Git是非常的重要的，但是为什么呢？这就需要从企业级的开发流程来说。
引入
我们知道，⼀个软件从零开始到最终交付，⼤概包括以下⼏个阶段：规划、编码、构建、测试、发布、部署和维护。
最初，程序比较简单，工作量不大，程序员⼀个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，⼀个人已经hold不住了，就开始出现了精细化分工。
- 开发团队：(尤其是敏捷团队)追求变化。
- 运维团队：追求稳定。
双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于 IT 价值的最大化。
为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革 ⸺ DevOps正式登上舞台。
DevOps（Development和Operations的组合词）是⼀种重视 “软件开发⼈员（Dev）” 和 “IT运维技术⼈员（Ops）” 之间沟通合作的文化、运动或惯例。透过自动化 “软件交付” 和 “架构变更” 的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在 DevOps 的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见 DevOps 的强大。
DevOps到底是什么意思？
系统开发环境
⾔归正传，对于开发人员来说，在系统开发过程中最常用的几个环境必须要了解⼀下。
- 开发环境：开发环境是程序猿们专门用于日常开发的服务器。为了开发调试方便，⼀般打开全部错误报告和测试工具，是最基础的环境。
- 测试环境：⼀个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。
- 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
- 生产环境：是指正式提供对外服务的线上环境，例如我们目前在移动端或PC端能访问到的APP都是生产环境。
这几个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。
Git 分支设计规范
环境有了概念后，那么对于开发人员来说，⼀般会针对不同的环境来设计分支。
| 分支 | 名称 | 适用环境 |
|---|---|---|
| master | 主分支 | 生产环境 |
| release | 预发布分支 | 预发布 / 测试环境 |
| develop | 开发分支 | 开发环境 |
| feature | 需求开发分支 | 本地 |
| hotfix | 紧急修复分支 | 本地 |
注： 以上表格中的分支和环境的搭配仅是常用的⼀种，可视情况而定不同的策略。
以上跟大家讲解的是企业级常用的⼀种 Git 分支设计规范：Git Flow 模型。
master 分支
master 为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，⼀般由合并 release 分支得到。主分支作为稳定的唯⼀代码库，任何情况下不允许直接在 master 分支上修改代码。产品的功能全部实现后，最终在 master 分支对外发布，另外所有在 master 分支的推送应该打标签（tag）做记录，方便追溯。
master 分支不可删除。
release 分支
release 为预发布分支，基于本次上线所有的 feature 分支合并到 develop 分支之后，基于 develop 分支创建。可以部署到测试或预发布集群。命名以 release/ 开头，建议的命名规则: release/version_publishtime 。release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以 release 分支代码为基准进行提测。如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
release 分支属于临时分支，产品上线后可选删除。
develop 分支
feature 分支
feature 分支通常为新功能或新特性开发分支，以 develop 分支为基础创建 feature 分支。命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。新特性或新功能开发完成后，开发人员需合到 develop 分支。
一旦该需求发布上线，便将其删除。
hotfix 分支
hotfix 分支为线上 bug 修复分支或叫补丁分支，主要用于对线上的版本进行 bug 修复。当线上出现紧急问题需要马上修复时，需要基于 master 分支创建 hotfix 分支。命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix 。
当问题修复完成后，需要合并到 master 分支和 develop 分支并推送远程。⼀旦修复上线，便将其删除。
开发场景 - 基于git flow模型的实践
DevOps研发平台
腾讯
阿里云
gitee
修复测试环境 Bug
修改预发布环境 Bug
- 如果存在，修复流程与修复测试环境 Bug 流程⼀致。
- 如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
修改正式环境 Bug
- 如果存在，修复流程与修复测试环境 Bug 流程⼀致。
- 如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。
紧急修复正式环境 Bug
拓展实践
阿里飞流 flow 分支模型，及项目版本管理实践：gitee
