说明：以下是前期公司内部试行的简单的代码分支版本流程管理规范，规范其实和运维有很大的关联，随着管理方式和流程的完善，代码版本管理流程也是会改变的。仅供参考！！！
分支说明
dev-xxx为开发分支，xxx表示版本，建议使用上线年月日时间串，比如dev-20180612或 为需求功能点名称，比如dev-xx需求test为测试分支 (如果存在多版本同时测试，可能存在test-xxx分支，意思是多个测试环境，有做压测或者是功能测试的)master主分支为uat回归测试分支（预生产/准生产分支）。（此分支会做分支保护，不允许直接 push 和 只有主程序员可以 merge ）prod为生产发布分支prod-xxx为生产上线后备份tag
分支版本流程管理
图解：
- （1）在主工程仓库，基于
prod分支创建新开发分支dev-xxx； - （2）开发人员
fork主仓库到自己名下，（如果原来已经 fork 过，可以通过更新的方式更新获取到最新的master和dev-xxx代码），切换到分支dev-xxx进行开发； - （3）平时开发正常提交到自己的
fork仓库，适当时机PRmerge 到 远程项目主仓库对应的dev-xxx分支； - （4） 如果要提测了，将
dev-xxx分支代码合并提交到test分支；（建议是fork仓库的分支dev-xxx提交到了远程主仓库的dev-xxx分支，再用主仓库的远程dev-xxx分支合并到test分支） - （5）QA 测试过程提 bug，开发人员改 bug 的话，就是重复（3）（4）步骤；
- （6）QA 验证
test分支代码通过后，就将test分支 PR 合并到master分支，进行回归测试； - （7）如果
uat测试有 bug，重复（3）（4）（6）步骤；如果uat测试失败，运维要回滚uat环境和生产一致。 - （8）
uat测试通过，产品验收通过，则将代码覆盖更新到prod分支，进行上线安排，上线出问题还是要有紧急回滚机制。 - （9）上线验收成功后，给生产
prod分支版本打标签，如prod-xxxx（xxx 为上线日期）
(一个完整流程到此结束)
情景举例说明
迭代新版本
当有新需求开发时，一般是经过需求评审后，定下的冲刺迭代版本，评估了开发周期，确认了上线时间。
- 如果有多个需求（迭代）并行开发，上线时间不一样，那就是不同版本，这时候，需要基于
prod-xxxx创建一个分支出来，比如取名为dev-xxxx，然后基于此分支开发同版本的需求上线，要提交 Jenkins 构建的话就 merge 到对应的测试分支。 - 如果新需求都是同一个版本，步骤同上，只是一个 dev 分支
- 以上的新需求分支开发完成后，提测的话就
PR到test分支，QA 完成功能测试没问题后，将test分支 merge 到master分支进行回归测试。
生产上有 bug，需紧急修复上线
- 基于
prod-xxx创建分支修改 bug，分支名称为bug-prod-xxx，改完自验没问题需要提交测试的时候，merge到相应测试分支（如test），Jenkins构建后验证通过，上线生产。上线完成后，别忘记了备份新生产分支prod-xxxx。然后其他正常使用的分支，需要拉取最新生产分支代码prod-xxxx，保证拥有最新的生产分支代码，避免 bug 又上线了（这个过程在以上把 master 定为准生产分支时规避掉了）。
故事举例：
（一）冲突的新需求情景：
2018-06-09 CRM 前端上线了，上线后开发人员备份了生产分支代码为 prod-20180609，第二天，前端开发人员紧接着开发新需求，并且新需求有两个版本，版本一 是在下周上线；版本二 是在月底上上线。版本一和版本二是不同的开发人员，启动开发时间是一样的。这时候，开发人员应该基于 master 分支创建出两个分支，假设为 dev-20180618-需求1 和 dev-20180625-需求2，然后他们都是各自在各自分支里边开发，相互不影响。
- 提交测试前的任何分支，都要拉取一下主分支
master，合并最新生产代码（因为可能会有遗漏，有人改过没更新同步你们的分支），然后再PR到test分支测试。
（二）线上 BUG 情景：
问题来了：上线后第三天，线上用户反馈了 bug，需要紧急修复。
做法：基于远程仓库主分支的版本标签 prod-20180609 创建新分支bug-prod-xxx，在此新分支修改 bug，自测没问题后 PR 到主仓库 test（如果该分支已经被新需求占用，可以创建新分支test-bug，Jenkins 构建选对就好），jenkins构建后 QA 测试，没问题后，将 test 分支 merge到 master 分支，没问题后再覆盖更新到 prod上线,上线完成后，备份新生产分支，打标签prod-xxxx。
（三）公共代码（非需求代码变动）情景：
修改公共代码的同学，需要自己创建一个专门用来改公共代码的分支出来。公共代码或者是公共类库和基础服务等代码改动了，也要和业务代码一样，提测走完测试流程。
总结
本文属于《前端团队工程化记录》 的一小节内容，更多请前往了解。