• 分布式合作工作流


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

      

    1. 需求评审、技术评审、UI切图
    2. 研发接受需求,分解任务:  假设任务为:张三---->任务1、李四----->任务2、王五----->任务3;
    3. 那么张三、李四、王五都开始从的develop 分支拉取自己的feature分支(名字以各自任务为主);接下来我们以张三为例子
    4. 张三在自己的feature上面开始coding;【备注:分支名 featre/zhangsan-1.1.0-target1】
    5. Coding、coding、coding ... 漫漫长夜,唯有杜康可以解忧
    6. 完成后,开始单独任务提测;(没有李四、王五的代码)
    7. 提测同时,根据内容情况自己觉得是否需要codeReview
    8. 如果需要则在gitlab上面,提交一个mergeRequest请求 (我们是将当前的feature下的分支mergeRequest到 develop分支中)
    9. mergeRequest需要指定的codeReviewer,进行代码codeReview
    10. 等测试和产品经理以及codeReviewer 都完成之后,合并mergerRequest到develop
    11. develop 分支需要等待张三、李四、王五都合并代码并解决冲突;(可能会产生冲突)
    12. develop 拉release分支进行线上回归测试,此时才是发版的真正所有代码
    13. 测试最终完成之后,开始发版
    14. 发布到AppStore审核
    15. 将release 分支 合并到develop
    16. 最后将develop 合并的 master(master权限不是每个人都拥有,需要指定的比较高级人员拥有)
    17. 打tag
  • 相关阅读:
    Leetcode86.分隔链表
    Leetcode39.组合总和
    Leetcode31.下一个排列
    剑指Offer35.复杂链表复制
    剑指Offer14-I.剪绳子
    剑指Offer38.字符串的排序
    Leetcode29.两数相除
    232. Implement Queue using Stacks
    程序员跳槽指南
    226. Invert Binary Tree
  • 原文地址:https://www.cnblogs.com/kingbo/p/7442740.html
Copyright © 2020-2023  润新知