一、先讲背景

git分支主要有以下：
主分支：master，保证所有已发布到生产环境的分支都已merge到master，并且，新分支比如从master创建
日常分支：daily，本地开发和测试环境使用，保证所有的已上生产和发布测试的分支都已merge到daily
其他分支：版本分支或bug分支，从master拉取，并在merge到master后删除
前端团队采用如下开发流程:
（接到版本需求后，假设不需要后端接口配合，或后端接口已开发完毕）

二、开发阶段

第一阶段（本地开发+测试环境阶段）

step1：master创建一个新分支featrue-2019-2，此为版本分支，并拉取到本地，使用SwicthHosts将本地开发环境映射到日常环境，也称测试环境，在本地开发调试

step2：本地开发后，使用sourcetree保存并提交到远程featrue-2019-2分支，你使用git命令也是一样

step3：拉取日常环境分支daily，并将featrue-2019-2 merge到 daily

step4：使用JenKins（日常环境账号）登录后构建daily分支，表示对daily的代码执行npm run

build+push，构建成功后通知测试人员 step5：若测试有问题，修改后，重复step2、step3、step4，直到测试通过

第二阶段（预发阶段）

step1：merge master 到 featrue-2019-2，保证featrue-2019-2已包含所有的生产代码

step2：使用JenKins（预发环境账号）登录后构建featrue-2019-2分支，构建成功后通知测试

step3：若测试有问题，检查测试环境是否也有此问题，若有，则要返回第一阶段的step2

第三阶段（生产阶段）

step1：此分支发预发后，若有别的分支发了生产，则需要执行merge master 到

featrue-2019-2，保证featrue-2019-2已包含所有的生产代码

step2：使用JenKins（生产环境账号）登录后构建featrue-2019-2分支，构建成功后通知测试

step3：featrue-2019-2 merge 到 master，并删除featrue-2019-2，

step4：若测试有问题，汇总问题，从master拉取bug分支，例如可命名为featrue-2019-2-bug，从第一阶段开始，开启一个新的版本开发

三、分支原则

1、保证master分支是唯一主分支
2、所有版本分支，所有需求，所有代码，必须按“照构建日常——>构建预发——>构建生产”的顺序执行
3、所有版本分支只开发此版本相关内容，不可混合其他版本需求开发
4、分支发布生产后，必须尽快merge到master
5、分支的生命周期，从master上拉取开始，到merge到master以后结束，一个分支尽量只使用一次，即merge到master以后就删除
6、不要频繁发布生产，日常和预发不受限制

四、预发环境的必要性

以前的公司，只有测试/预发环境和正式/生产环境，来到这家公司后，才了解到预发环境的必要性。
测试环境，用来测试代码没有问题，但是测试环境里都是测试数据，和真实数据差别很大，大家都知道，对于前端来说这些数据的不同会造成特殊情况存在，例如测试环境的数据不合法。
而预发环境则是真实数据，基本上用户在预发环境的所见，99%等同于在生产环境的所见，所以，必要性可想而知。