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