一. 常见问题
1. 在Gerrit 平台上使用Merge的方式合入代码。
Gerrit是集中式工作流，不推荐使用Merge方式合入代码，应该是在主干分支开发后，直接Push。
2. 不了解保护分支，Code Review, CI 等概念，研发流程不规范。
保护分支:防止用户直接向主干分支提交代码，必须通过PR来进行合入。
Code Review, Cl: 都是在合入前的检查策略，Code Review是人工进行检查，CI 则是通过一些定制化的脚本来进行一些校验。
3.代码历史混乱，代码合并方式不清晰。
不理解Fast Forward和Three Way Merge的区别，本地代码更新频繁的使用Three Way的方式，导致生成过多的Merge节点，使提交历史变得复杂不清晰。
二. 不同的工作流
2.1集中式工作流
- 什么是集中式工作流?
只依托于master分支进行研发活动
- 工作方式
- 获取远端master代码
- 直接在master分支完成修改
- 提交前拉取最新的master代码和本地代码进行合并(使用rebase),如果有冲突需要解决冲突
- 提交本地代码到master
2.2集中式工作流- -Gerrit
Gerrit是由Google开发的一款代码托管平台，主要的特点就是能够很好的进行代码评审。
在aosp (android open source project)中使用的很广，Gerrit 的开发流程就是种集中式工作流。
- 基本原理
- 依托于Change ID概念，每个提交生成一个单独的代码评审。
- 提交上去的代码不会存储在真正的refs/heads/下的分支中，而是存在一个refs/for/的引用下。
- 通过refs/meta/config下的文件存储代码的配置，包括权限，评审等配置，每个Change都必须要完成Review后才能合入。
- 优点
- 提供强制的代码评审机制， 保证代码的质量
- 提供更丰富的权限功能，可以针对分支做细粒度的权限管控
- 保证master的历史整洁性
- Aosp 多仓的场景支持更好
- 缺点
- 开发人 员较多的情况下，更容易出现冲突
- 对于多分支的支持较差，想要区分多个版本的线上代码时，更容易出现问题
- 一般只有管理员才能创建仓库，比较难以在项目之间形成代码复用，比如类似的fork操作就不支持。
2.3分支管理工作流- -GitFlow
Git Flow是比较早期出现的分支管理策略。
- 包含五种类型的分支
- Master:主干分支
- Develop:开发分支
- Feature:特性分支
- Release:发布分支
- Hotfix:热修复分支
●优点
如果能按照定义的标准严格执行，代码会很清晰，并且很难出现混乱。
●缺点
流程过于复杂，上线的节奏 会比较慢。由于太复杂，研发容易不按照标准执行，从而导致代码出现混乱。
3.3分支管理工作流Github Flow
Github的工作流，只有一个主干分支， 基于Pull Request往主干分支中提交代码。
- 选择团队合作的方式
- owner创建好仓库后，其他用户通过Fork的方式来创建自己的仓库，并在fork的仓库上进行开发
- owner创建好仓库后，统一给团队内成员分配权限，直接在同一一个仓库内进行开发
3.4代码合并
Fast-Forward
不会产生一个merge节点，合并后保持个线性历史， 如果target 分支有了更新，则需要通过rebase操作更新source branch后才可以合入。
Three-Way Merge
三方合并，会产生一个新的merge节点
3.5如何选择合适的工作流
- 选择原则
没有最好的，只有最合适的
- 针对小型团队合作，推荐使用Github工作流即可
- 尽量保证少量多次，最好不要一 次性提交上千行代码
- 提交Pull Request后最少需要保证有CR后再合入
- 主干分支尽量保持整洁，使用fast -forward合入方式，合入前进行rebase 大型团队合作，根据自己的需要指定不同的工作流，不需要局限在某种流程中。
三. 个人感悟
- 抓紧时间
- 多敲代码
- 注意代码的安全性
- 努力提高效率和代码的质量
