简版Git工作流

简版Git工作流

58到家、快狗（58速运）、58家政收简历啦~
最近想换工作的同学~ 欢迎拿简历砸我~ 加我微信：15501423004 （记得备注 内推 哈~）

说明

前段时间，我们部门由于工作流不规范导致了一系列问题，低效、线上事故、项目延期、代码质量低等问题。老大决定规范一下流程，我也参与其中。
随着工作经验的增加，其实你会发现并没有完美的Git工作流，只有完美的团队配合。
没必要死板的刻意的在团队内执行某一种功能大而全的工作流。
工作流应该在工作中慢慢演化出来的，应该根据公司的基础设施、各部门配合方式、开发人员水平、项目组需求数等因素，选择一个成本和效益平衡的最优解。

目的

• 规范开发流程
• 提高交付质量
• 加入代码审查

分支介绍

• master：用来记录Tag，以及develop分支的代码备份
• develop：主开发分支
• feature-xxx：功能分支
• test：测试环境分支、pPR分支
• box：沙箱环境分支、PR分支
• hotfix：紧急BUG修改分支

开发流程介绍

1. develop => feature-1 从develop分支拉取功能分支，开发功能1。
2. feature-1 => test 开发结束后，提PR。通过则整合代码进test环境（测试阶段），驳回则修改后再次提交PR，直至测试通过。
3. feature-1 => box 测试通过后，feature-1如果需要上线则提PR申请合并到box分支，进行灰度测试。
4. feature-1 => develop 灰度通过后，将feature-1分支整合进develop分支，准备上线。
5. develop => master 上线成功后，将develop分支同步至master分支并打上Tag。并删除feature-1功能分支。
6. develop => feature-hotfix 线上紧急bug，从develop分支拉feature-hotfix分支，流程与普通feature一致。
7. PR流程：在GitLab上提PR后，邮件或钉钉通知审核人。审核人在GitLab或IDE上进行review。

可视化工具（建议从命令行用起）

• GitLab
• IDE 自带
• SmartGit、SourceTree

总结

方案	学习成本	依赖	场景	备注
现有方案	小	git	规范流程	能满足目前开发需求，对接自动化构建部署，成本较小容易出结果。
GitFlow	大	SmartGit	多人开发，分支管理	经得住时间考验的分支管理流程，能力上肯定是Gitflow更强。对团队的成长意义更大。

讨论

1. 提PR的粒度太大，PR的实际意义可以跟Eslint效果一致。
2. 衍生问题，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