Git研发流程
不同的工作流
集中式工作流
只依托于master分支进行研发活动
工作方式
- 获取远端master代码
- 在master分支完成修改
- 提交前拉取最新的master代码和本地代码进行合并，若有冲突需解决冲突
- 提交本地代码到master
集中式工作流——Gerrit
基本原理
优点
- 提供强制的代码评审机制，保证质量
- 提供丰富的权限功能，可针对分支做细粒度的权限管控
- 保证master的历史整洁性
- Aosp多仓场景支持更好
缺点
- 开发人员较多时容易出现冲突
- 对多分支的支持较差，想区分多个版本的线上代码时，易出现问题
- 一般只有管理员可创建仓库，难以在项目间形成代码复用
分支管理工作流
（1）Git Flow
分支类型丰富，规范严格
包含五种类型分支
- Master主干分支
- Develop开发分支
- Feature特性分支
- Release发布分支
- Hotfix热修复分支
优点
按定义的标准严格执行，代码会很清晰
缺点
流程过于复杂，上线节奏慢，太复杂使研发不易按标准执行，从而导致代码混乱
（2）GitHub Flow
只有主干分支和开发分支，规则简单
有两种团队合作的方式
- owner创建仓库，其他用户通过fork的方式创建自己的仓库，在fork仓库上开发
- owner创建仓库，统一给团队内成员分配权限，在同一个仓库内开发
（3）Gitlab Flow
在主干分支和开发分支上构建环境分支、版本分支，满足不同的发布与环境需要
代码合并
Fast-Forward
不会产生一个merge节点，合并后保持一个线性历史，如果target分支有了更新，则需要通过rebase操作更新source分支后才可以合入
Three-Way Merge
三方合并，产生一个新的merge节点
