版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/aaaaaaliang/article/details/80476685
简版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