系统开发环境
对于开发⼈员来说，在系统开发过程中最常⽤的⼏个环境必须要了解⼀下：
-
开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误报告和测试⼯具，是最基础的环境
-
测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境
-
预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器
-
⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境
这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线，总结起来如下图：
对于规模稍微⼤点的公司来说，可不⽌这么⼏个环境，⽐如项⽬正式上线前还存在仿真/灰度环境，再⽐如还存在多套测试环境，以满⾜不同版本上线前测试的需要。
⼀个项⽬的开始从设计开始，⽽⼀个项⽬的成功则从测试开始。⼀套良好的测试体系可以将系统中绝⼤部分的致命Bug解决在系统上线之前。测试系统的完善和成熟也是衡量⼀个软件企业整体⽔平的重要指标之⼀，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产⽣直接的效益，但是它却是软件质量的最终保障，乃⾄项⽬能否成功的重要因素！
Git分⽀设计规范-Git Flow模型
对于开发⼈员来说，⼀般会针对不同的环境来设计分⽀：
| 分支 | 名称 | 设用环境 |
|---|---|---|
| master | 主分支 | 生产环境 |
| release | 预发布分支 | 预发布/测试环境 |
| develop | 开发分支 | 开发环境 |
| feature | 需求开发分支 | 本地 |
| hotfix | 紧急修复分支 | 本地 |
以上表格中的分⽀和环境的搭配仅是常⽤的⼀种，可视情况⽽定不同的策略
master分支
1.master分支为主分支，该分⽀为只读且唯⼀分⽀，⽤于部署到正式发布环境，⼀般由合并release 分⽀得到
2.主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在master分⽀上修改代码
3.产品的功能全部实现后，最终在 master分⽀对外发布，另外所有在master分⽀的推送应该打标签（tag）做记录，⽅便追溯
4.master分⽀不可删除
release分支
1.release 为预发布分⽀，基于本次上线所有的feature分⽀合并到 develop 分⽀之后，基于 develop 分⽀创建。可以部署到测试或预发布集群
2.命名以release开头，建议的命名规则: release/version_publishtime
3.release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码为基准进⾏提测
4.如果在 release分⽀测试出问题，需要回归验证develop 分⽀看否存在此问题
5.release分⽀属于临时分⽀，产品上线后可选删除
develop分支
1.develop为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及bug修复后的代码。可部署到开发环境对应集群
2.可根据需求⼤⼩程度确定是由feature 分⽀合并，还是直接在develop分支上⾯开发
feature分支
1.feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分支
2.命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature
3.新特性或新功能开发完成后，开发⼈员需合到develop分支
4.⼀旦该需求发布上线，便将feature分支删除
hotfix分支
1.hotfix分⽀为线上bug修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏bug修复。当线上出现紧急问题需要⻢上修复时，需要基于master分支创建hotfix分支
2.命名以hotfix/开头，建议的命名规则为：hotfix/user_createtime_hotfix
3.当问题修复完成后，需要合并到master分支和develop 分⽀并推送远程。一旦修复上线，便将其删除
一张图总结就是：
Bug修复
修复测试环境Bug
在develop测试出现了Bug，建议在feature分支上进行修复。修复后的提测上线流程与新需求加⼊的流程⼀致
修改预发布环境Bug
在release测试出现了Bug，首先要回归下develop分支是否同样存在这个问题。
- 如果存在，修复流程与修复测试环境Bug流程⼀致
- 如果不存在，这种可能性⽐较少，⼤部分是数据兼容问题，环境配置问题等
修改正式环境Bug
在master测试出现了Bug，首先要回归下release和develop分支看是否同样出现这个问题
- 如果存在，修复流程修复测试环境Bug流程⼀致
- 如果不存在，这种可能性也⽐较少，⼤部分是数据兼容问题，环境配置问题等。
紧急修复正式环境Bug
需求在测试环节未测试出Bug，上线运⾏⼀段时候后出现了Bug，是需要紧急修复的，有的企业⾯对紧急修复时，⽀持不进⾏测试环境的验证，但还是建议验证下预发布环境。
- 此时可以基于
master分支创建hotfix/xxx分支，修复完毕后发布到master分支进行验证，验证完毕后，将master分支合并到develop分支，同时删掉hotfix/xxx分支