概况
当前文档包涵开发流程规范与上线（OP）流程规范。
通过规范开发流程可以严格控制线上分支的代码质量及稳定性。使用成熟的工作流程模型，可以使团队协作更加流畅。
通过规范上线（OP）流程，保证线上环境的稳定，明确职责。
涉及人员
- 研发工程师
- 代码审核员（技术负责人或由技术负责人指定的研发工程师，不可以是开发者本人）
- 产品经理
- 测试工程师（未到岗前，产品经理负责）
多人协作流程与规范
一、工作流
选用GitFlow工作流模式作为协作流程规范。
1、gitflow
Gitflow工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了一个健壮的用于管理大型项目的框架。
Gitflow为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。 除了使用功能分支外在做Bug修复、维护和预发布时也使用各自的分支。同时通过Pull Requests、隔离实验性开发实现更高效的协作。
2、工作方式
Gitflow工作流仍然用一个远程仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到中央仓库中。
二、主要分支: Master、Develop
Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。
- Master(绿色): 永远处在 production-ready 状态
- Develop(橙色): 最新的下次发布开发状态
三、支援性（临时）分支:
1、Feature功能分支
每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。
Feature(蓝色): 开发新功能都从 develop 分支出来，完成后 merge 回 develop
2、release发布分支
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。
使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。
常用的分支约定：
用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*
Release(黄色): 准备要 release 的版本，只修 bugs。从 develop 分支出来，完成后 merge 回 master 和 develop
3、hotfix维护分支
维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。
- Hotfix(灰色): 等不及 release 版本就必须马上修 master 赶上线的情况。会从 master 分支出来，完成后 merge 回 master 和 develop
四、代码Review
使用pull request进行代码review
在Gitflow工作流中使用Pull Request让开发者在发布分支或是维护分支上工作时， 可以有个方便的地方对关于发布分支或是维护分支的问题进行交流。
当一个功能、发布或是热修复分支需要Review时，开发者简单发起一个Pull Request， 团队的其它成员会通过Bitbucket收到通知。
新功能一般合并到develop分支，而发布和热修复则要同时合并到develop分支和master分支上。 Pull Request可能用做所有合并的正式管理。
OP流程
规范开发协作流程之后，其实OP流程就相对简单了。
首先规定所有代码合并到Develop、或Master都经过了测试、review及验收。
此时OP只需要执行线上部署即可。
一、基本约定
- master 技术负责人 读写，开发 只读
- develop 技术负责人 读写，开发 只读
- release/hotfix/hotfix 等需要合并到 master的分支需要由技术负责人创建
- 其它临时分支，ALL 读写
二、一般开发任务的OP流程
三、紧急任务的OP流程
职责分工
一、产品经理
- 参与技术方案确认
- 预上线测试
- 线上回归及后续跟进
二、研发工程师
- 代码开发、bug修复（必须自测完成才能提交）
- 配合预上线测试
1、一般开发
（1）、更新版本库
git pull origin master:master
git pull origin develop:develop
（2）、创建功能分支
git checkout develop
git checkout -b feature/<功能名称>
（3）、开发和测试
（4）、提交功能分支
git push origin feature/<功能名称>
（5）、通过gitlab申请review (合并目标develop)
（6）、解决冲突
git checkout develop
git pull origin develop:develop
git merge feature/<功能名称>
（7）、提交合并结果
git push origin develop: feature/<功能名称>
（8）、检查通过
git branch -D feature/<功能名称>
2、紧急修复
（1）、获取修复用分支
git checkout master
git pull origin master:master
git checkout -b hotfix/<编号>
（2）、开发和测试
（3）、提交功能分支
git push origin hotfix/<编号>
（4）、通过gitlab申请review (合并目标master)
（5）、解决冲突
git checkout master
git pull origin master:master
git merge hotfix/<编号>
（6）、提交合并结果
git push origin master:hotfix/<编号>
（7）、检查通过
git branch -D hotfix/<编号>
3、预上线集成
（1）、获取集成分支
git fetch origin release/<编号>: release /<编号>
git checkout release /<编号>
（2）、测试、微调 （严禁引入新功能和大的修改，针对某一个bug或功能超过50行的修改即认为大型修改，本次上线终止）
（3）、提交功能分支
git push origin release /<编号>
（4）、通过gitlab申请review (合并目标master)
（5）、解决冲突
git checkout master
git pull origin master:master
git merge release /<编号>
（6）、提交合并结果
git push origin master: release /<编号>
（7）、检查通过
git branch -D release /<编号>
4、代码审核员
代码review，结果合并
5、技术负责人
任务分配
临时分支创建工作：releasehotfixhotfix
代码review，结果合并（结果需要同时合并到master、develop）
6、OP
按邮件说明，将master指定版本上线
示例
下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。
一、创建开发分支
第一步为master分支配套一个develop分支。简单来做可以本地创建一个空的develop分支，push到服务器上：
git branch develop
git push -u origin develop
以后这个分支将会包含了项目的全部历史，而master分支将只包含了部分历史。其它开发者这时应该克隆中央仓库，建好develop分支的跟踪分支：
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop
现在每个开发都有了这些历史分支的本地拷贝。
二、程序员A和程序员B开始开发新功能
这个示例中，程序员A和程序员B开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于master分支，而是应该基于develop分支：
git checkout -b some-feature develop
他们用老套路添加提交到各自功能分支上：编辑、暂存、提交：
git status git add <some-file> git commit
三、程序员A完成功能开发
添加了提交后，程序员A觉得她的功能OK了。如果团队使用Pull Requests，这时候可以发起一个用于合并到develop分支。 否则她可以直接合并到她本地的develop分支后push到中央仓库：
git pull origin develop git checkout develop git merge some-feature git push git branch -d some-feature
第一条命令在合并功能前确保develop分支是最新的。注意，功能决不应该直接合并到master分支。 冲突解决方法和集中式工作流一样。
四、程序员A开始准备发布
这个时候程序员B正在实现他的功能，程序员A开始准备她的第一个项目正式发布。 像功能开发一样，她用一个新的分支来做发布准备。这一步也确定了发布的版本号：
git checkout -b release-0.1 develop
这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支。
只要程序员A创建这个分支并push到中央仓库，这个发布就是功能冻结的。任何不在develop分支中的新功能都推到下个发布循环中。
五、程序员A完成发布
一旦准备好了对外发布，程序员A合并修改到master分支和develop分支上，删除发布分支。合并回develop分支很重要，因为在发布分支中已经提交的更新需要在后面的新功能中也要是可用的。 另外，如果程序员A的团队要求Code Review，这是一个发起Pull Request的理想时机。
git checkout master git merge release-0.1 git push git checkout develop git merge release-0.1 git push git branch -d release-0.1
发布分支是作为功能开发（develop分支）和对外发布（master分支）间的缓冲。只要有合并到master分支，就应该打好Tag以方便跟踪。
git tag -a 0.1 -m "Initial public release" master git push --tags
Git有提供各种勾子（hook），即仓库有事件发生时触发执行的脚本。 可以配置一个勾子，在你push中央仓库的master分支时，自动构建好对外发布。
六、最终用户发现bug
对外发布后，程序员A回去和程序员B一起做下个发布的新功能开发，直到有最终用户开了一个Ticket抱怨当前版本的一个Bug。 为了处理Bug，程序员A（或程序员B）从master分支上拉出了一个维护分支，提交修改以解决问题，然后直接合并回master分支：
git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push
就像发布分支，维护分支中新加这些重要修改需要包含到develop分支中，所以程序员A要执行一个合并操作。然后就可以安全地删除这个分支了：
git checkout develop git merge issue-#001 git push git branch -d issue-#001
到了这里，但愿你对集中式工作流、功能分支工作流和Gitflow工作流已经感觉很舒适了。 你应该也牢固的掌握了本地仓库的潜能，push/pull模式和Git健壮的分支和合并模型。
记住，这里演示的工作流只是可能用法的例子，而不是在实际工作中使用Git不可违逆的条例。 所以不要畏惧按自己需要对工作流的用法做取舍。不变的目标就是让Git为你所用。