团队代码协作规范 - 基于git flow工作流
git-flow
分支解释：
- master :不允许开发者对代码进行修改和提交。该分支上的代码随时可以部署到生产环境
- develop:是开发过程中代码中心分支。不允许开发者直接进行修改和提交（只允许MR(PR)，以下MR 均指 Merge Request）
- Release:临时分支:上线的准备工作和预演环境的bug。绝不能包含需求变更或功能变更等重大修正。这一阶段的提交数应该限制到最低
- Hotfix:临时分支,修复紧急bug的分支；紧急bug定义：无法等到下个版本的bug
- Feature:开发分支，已完成的feature 需要在适当时间删除；需要其他开发者对对此次MR进行code review，在通过审核后Accept Merge Request 发布到dev
优势：
- 通过不同分支间的交互规划了一套软件开发、集成、部署的工作流
- 基于不同分支完成不同环境的发布
- CodeReview，开发者的代码，可以在MR 到dev branch 过程进行peer review，再MR 到release branch 时做 lead review
- 可直接集成各种CI tools，进行持续发布；不过一般情况是，测试环境采取 auto deploy，预演和生产环境 manual deploy
实施要求：
- 整个团队的纪律性要求很高
- 要求团队成员熟练掌握git 指令、gitflow原理流程
- 有git-flow 扩展指令集，推荐使用sourceTree 做为git-flow gui 工具
注意事项：
- 两条主分支：develop & master，贯彻整个流程始终
- feature 分支，粒度划分要细，建议不超过一周，杜绝出现long-lived-branches;多人协作时；建议每日从dev pull 一次代码；建议发起mr前均需要pull 一次代码，修复冲突后才能mr到dev 分支
- develop和master分支，需要设置为protected branch，杜绝直接commit和merge代码
- release分支，只做bug 修复，bug修复完后，发布上线，同时要将修复的代码 mr 到dev
- hotfix分支，线上出现bug需要进行紧急修复，可以从master 拉一个hotfix分支，修复后及时mr 到master 和 dev 分支；线上出现重大bug，或者bug一时难以修复，需要基于上一个tag进行回滚操作。
产品发布流程 - 基于git flow工作流
git-flow
(1)(2)(3)步骤说明
(1)上测试环境，feature 通过merge request 到dev：
- 在 MR 前，需要从dev 作 pull 操作
- 在 MR 前，需要功能自测 ，核心服务通过unit test
- MR 过程中需要assign to peer developer 作 Peer review，双方均需对此次mr 负有责任；Code Reviewer之Peer Review，审查代码逻辑错误，建议更好的实现
- MR 完成后，基于dev 分支 发布到测试环境；（可以手动，也可以自动）
- 发布到测试环境后，由QA&UI 负责校验 任务是否达到DoD标准，未能通过检验，返回给研发进行修改
(2)上预发布环境，从dev 发起 merge request 到release：
- 在MR前，需要当前sprint 内所有task 均达到DoD标准，所有bug fixed
- 在MR前，需要QA/Tester通过对测试环境的功能测试、性能测试、兼容性测试
- 在MR前，需要UI Designer通过对产品进行还原度确认
- 在MR前，需要由Team Leader/架构师 作 Lead Review，对代码架构进行审查，保证代码的重构与复用
- 基于release 分支发布到预发布环境；release 分支的改动要在上线前MR回dev和master
- 发布release，意味着此次sprint 的研发结束，后续的研发 就要算作next release 版本
(3)上生产环境，从release 发起merge request 到 master：
- 在MR前，需要通过QA/Tester通过All Test Case的回归测试
- 在MR前，需要需求方／PO confirmed，可以通过sprint review meeting 达成
- 在MR后，需要基于master分支 建立tag进行备份
- 发布上线后，做冒烟测试
- 线上出现重大异常或一时无法修复的异常，需要即可基于上一个的tag进行回滚，修复完成后再重新上线
注意情况：
- (1)(2)(3)在服务器到位情况下，需要优先配置好jenkins 各个环境的deploy item 配置
- 上线频率需要控制好，一般约定周二、周四，一旦存在问题可以第二日进行修复
备注
以上流程，适用 多人协作、持续迭代、产品各个环节质量和可用性要求高的情况；对于简单项目／对产品可用性要求不高的项目可以在流程上做适当精简分支；具体操作：
- 精简掉release分支，变更为基于dev 发布上预演；
- 精简掉hotfix分支，变更为基于feature 修复，dev 上做验证，再上线
- 上线过程不接受任何成员提交的新需求的MR，只接受bug 修复的代码MR
