这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
上一篇文章介绍了背后起源的故事，这一篇我们来仔细研究 Git 的使用方式。
由于基本的使用方式很容易就能在各种手册上看到，所以本文不涵盖基本使用方式，侧重于使用的流程和思路。
集中式工作流
集中式工作流的特点是其只依托于 master 分支进行研发活动。最主要的实践是 Google 开发的 Gerrit，侧重点是代码评审，其在 AOSP 的开发中有很广泛的应用。
工作方式
- 获取远端 master 的代码
- 直接在 master 分支完成修改
- 提交前拉取最新的 master 代码和本地的代码进行合并（使用 rebase），如果有冲突在此时解决冲突
- 提交本地代码到 master
优点
- 提供强制的代码评审机制，保证代码的质量
- 提供更丰富的权限功能，可以针对分支做细粒度的权限管控
- 保证 master 的历史整洁性
- AOSP 多仓库的场景支持更好
缺点
- 开发人员较多的情况下，更容易出现冲突
- 对于多分支的支持极差，想要区分多个版本的线上代码时，更容易出现问题
- 一般只有管理员才能创建仓库，比较难在项目之间形成代码复用
分支管理工作流
集中式工作流是在 Git 的使用实践中诞生的，其有多个变种，Git Flow、GitHub Flow、GitLabFlow。它们之间的差异不是很大。
分支管理的工作流是基于几个分支之间操作的。 其通常包含几种类型的分支，例如：
- 主干分支
- 开发分支
- 特性分支
- 发布分支
- 热修复分支
工作方式
- 其他用户创建自己的仓库或自己的分支
- 所有的代码在自己的分支上面进行提交
- 完成一定功能后，向主分支提交 PR（GitHub）或 MR（GitLab），请求将当前分支合并入主分支
优点
如果能按照定义的标准严格执行，代码会很清晰，并且很难出现混乱。
缺点
流程过于复杂，上线的节奏会比较慢。由于其过于复杂，研发容易不照标准执行，从而导致代码出现混乱。
总结
没有最好的工作流程，只有最合适的工作流程。而对于一般小型规模的团队的话，使用 GitHub 是最佳的。
