简版Git工作流
58到家、快狗(58速运)、58家政收简历啦~
最近想换工作的同学~ 欢迎拿简历砸我~ 加我微信:15501423004 (记得备注 内推 哈~)
说明
前段时间,我们部门由于工作流不规范导致了一系列问题,低效、线上事故、项目延期、代码质量低等问题。老大决定规范一下流程,我也参与其中。
随着工作经验的增加,其实你会发现并没有完美的Git工作流,只有完美的团队配合。
没必要死板的刻意的在团队内执行某一种功能大而全的工作流。
工作流应该在工作中慢慢演化出来的,应该根据公司的基础设施、各部门配合方式、开发人员水平、项目组需求数等因素,选择一个成本和效益平衡的最优解。
目的
- 规范开发流程
- 提高交付质量
- 加入代码审查
分支介绍
- master:用来记录Tag,以及develop分支的代码备份
- develop:主开发分支
- feature-xxx:功能分支
- test:测试环境分支、pPR分支
- box:沙箱环境分支、PR分支
- hotfix:紧急BUG修改分支
开发流程介绍
- develop => feature-1 从develop分支拉取功能分支,开发功能1。
- feature-1 => test 开发结束后,提PR。通过则整合代码进test环境(测试阶段),驳回则修改后再次提交PR,直至测试通过。
- feature-1 => box 测试通过后,feature-1如果需要上线则提PR申请合并到box分支,进行灰度测试。
- feature-1 => develop 灰度通过后,将feature-1分支整合进develop分支,准备上线。
- develop => master 上线成功后,将develop分支同步至master分支并打上Tag。并删除feature-1功能分支。
- develop => feature-hotfix 线上紧急bug,从develop分支拉feature-hotfix分支,流程与普通feature一致。
- PR流程:在GitLab上提PR后,邮件或钉钉通知审核人。审核人在GitLab或IDE上进行review。
可视化工具(建议从命令行用起)
- GitLab
- IDE 自带
- SmartGit、SourceTree
总结
方案 | 学习成本 | 依赖 | 场景 | 备注 |
---|---|---|---|---|
现有方案 | 小 | git | 规范流程 | 能满足目前开发需求,对接自动化构建部署,成本较小容易出结果。 |
GitFlow | 大 | SmartGit | 多人开发,分支管理 | 经得住时间考验的分支管理流程,能力上肯定是Gitflow更强。对团队的成长意义更大。 |
讨论
- 提PR的粒度太大,PR的实际意义可以跟Eslint效果一致。
- 衍生问题,test和预上线环境的bug需要走PR吗。
结论:都要走PR。所有人都可以审PR,只有当PR 的agree人数超过数量,才算通过。
例:10个人审PR,有3人点通过后,则此次PR通过。
参考资料
- GitLab提交PR: https://www.jianshu.com/p/6bcd082101c1
- GitFlow流程使用心得:https://blog.csdn.net/xuepiaohan2006/article/details/68950787
- SmartGit PR使用指南:https://www.syntevo.com/doc/pages/viewpage.action?pageId=16547953