接上篇git使用（1）| 青训营笔记 - 掘金 (juejin.cn)
常见问题
1、为什么配置了Git配置，但是依然没有办法拉取代码？
- 免密认证没有配。
- Instead Of配置没有配，配的SSH免密配置，但是使用的还是HTTP协议访问。
2、为什么Fetch了远端分支，但是看本地当前的分支历史还是没有变化？
- Fetch会把代码拉取到本地的远端分支，但是并不会合并到当前分支，所以当前分支历史没有变化。
git研发流程
集中式工作流
集中式工作量只依托于master分支进行研发活动
工作方式：
- 获取远端master代码
- 直接在master分支完成修改
- 提交前拉取最新的master代码和本地代码进行合并（使用rebase),如果有冲突需要解决冲突
- 提交本地代码到master
Gerrit
Gerrit是由Google开发的一款代码托管平台，主要的特点就是能够很好的进行代码评审。在aosp(android open source project)中使用的很广，Gerrit的开发流程就是一种集中式工作流。
基本原理
- 依托于Change ID概念，每个提交生成一个单独的代码评审。
- 提交上去的代码不会存储在真正的refs/heads/下的分支中，而是存在一个refs/for/的引用下。
- 通过refs/meta/config下的文件存储代码的配置，包括权限，评审等配置，每个Change都必须要完成Review后才能合入。
优点
- 提供强制的代码评审机制，保证代码的质量
- 提供更丰富的权限功能，可以针对分支做细粒度的权限管控
- 保证master的历史整洁性
- AoSp多仓的场景支持更好
缺点
- 开发人员较多的情况下，更容易出现冲突
- 对于多分支的支持较差，想要区分多个版本的线上代码时，更容易出现问题
- 一般只有管理员才能创建仓库，比较难以在项目之间形成代码复用，比如类似的fork操作就不支持。
分支管理工作流
| 工作流 | 特点 |
|---|---|
| Git Flow | 分支类型丰富，规范严格 |
| Github Flow | 只有主干分支和开发分支，规则简单 |
| Gitlab Flow | 在主干分支和开发分支之上构建环境分支，版本分支，满足不同发布 or 环境的需要 |
GitFlow
GitFlow是比较早期出现的分支管理策略。 包含五种类型的分支：
- Master:主干分支
- Develop:开发分支
- Feature:特性分支
- Release:发布分支
- Hotfix:热修复分支
优点 如果能按照定义的标准严格执行 代码会很清晰，并且很难出现混乱
缺点 流程过于复杂，上线的节奏会比较慢， 由于太复杂，研发容易不按照标准执行， 从而导致代码出现混乱。
GithubFlow
Github的工作流只有一个主干分支，基于pull request向主干分支中提交代码。团队合作方式一般为两种：
- owner创建好仓库后，其他用户通过Fork的方式来创建自己的仓库，并在fork的仓库上进行开发
- owner创建好仓库后，统一给团队内成员分配权限，直接在同一个仓库内进行开发
GitlabFlow
Gitlab推荐的工作量是在GitFlow和GithubFlow上做出优化，即保持了单一主分支的简便，又可以适应不同的开发环境。
原则：upstream first（上游优先），只有上游分支采纳的代码才可以进入到下游分支，一般上游分支就是master
代码合并
Fast-Forward：不会产生一个merge节点，合并后保特一个线性历史，如果target分支有了更新，则需要通过rebase操作更新source branch后才可以合入。
Three-Way Merge：三方合并，会产生一个新的merge节点。
