分布式合作工作流

淡淡回忆

　　今天整理了下我们公司GitFlow 工作流以及codeReview的流程 ;

• 需求评审、技术评审、UI切图
  
• 研发接受需求，分解任务：  假设任务为：张三---->任务1、李四----->任务2、王五----->任务3；
  
• 那么张三、李四、王五都开始从的develop 分支拉取自己的feature分支（名字以各自任务为主）；接下来我们以张三为例子
  
• 张三在自己的feature上面开始coding；【备注：分支名 featre/zhangsan-1.1.0-target1】
  
• Coding、coding、coding ... 漫漫长夜，唯有杜康可以解忧
  
• 完成后，开始单独任务提测；（没有李四、王五的代码）
  
• 提测同时，根据内容情况自己觉得是否需要codeReview
  
• 如果需要则在gitlab上面，提交一个mergeRequest请求 （我们是将当前的feature下的分支mergeRequest到 develop分支中）
  
• mergeRequest需要指定的codeReviewer，进行代码codeReview
  
• 等测试和产品经理以及codeReviewer 都完成之后，合并mergerRequest到develop
  
• develop 分支需要等待张三、李四、王五都合并代码并解决冲突；（可能会产生冲突）
  
• develop 拉release分支进行线上回归测试，此时才是发版的真正所有代码
  
• 测试最终完成之后，开始发版
  
• 发布到AppStore审核
  
• 将release 分支 合并到develop
  
• 最后将develop 合并的 master（master权限不是每个人都拥有，需要指定的比较高级人员拥有）
  
• 打tag