在上一篇笔记，介绍了创建项目、git初始化，再到git remote推送代码至远程仓库，完整地走了一遍创建并推送的流程，顺带实践了免密配置等操作，补充几个内容，remote 所分的ssh和http的区别在于，ssh是设置内部地址，http是设置外部地址，所以需要设置免密。key分为四种，这里只讲默认的和推荐的，默认的是rsa,但出于安全考虑，推荐使用ed25519。
这篇笔记讲讲使用Git研发流程 我们知道，团队开发项目，需要代码管理平台来提供支持，可以做到追溯历史版本、回退、保护分支等操作。非常需要弄清楚的是，团队协作的流程是怎样的，如何操作合情合理。实际的开发中难免会遇到问题。
1. 常见问题
(1). 在Gerrit平台使用Merge方式合入代码
Gerrit是集中式工作流，不建议用Merge，应该在主干分支开发后直接push
(2). 不了解保护分支
保护分支是为了防止用户直接向主干分支提交代码，必须通过PR合入
Code Review,Cl: 都是在合入前的检查策略，其中Code Review是人工检查，Cl则是利用定制化脚本检查
(3). 代码历史混乱、代码合并方式不清晰
不理解Fast-forward和Three-Way Merge区别，本地代码在更新的时候频繁使用Three Way的方式，导致生成过多的Merge节点。
2. 工作流
(1). 集中式工作流
- 特点：只针对主干分支进行开发，不存在其他分支。
- 代表平台：Gerrit/SVN
- 合入方式：Fast-forward
- 工作方式：获取远端master代码，直接在master分支修改，提交前拉取最新的master代码和本地代码进行合并（rebase），有冲突就解决冲突，最后提交本地代码到master
- （大概了解就行，更多情况下是使用的分支管理工作流）
(2). 分支管理工作流
- 特点：定义不同特性的开发分支、上线分支，在开发分支完成开发后，再通过MR/PR合入主干分支
- 代表平台：Github/Gitlab
- 合入方式：Fast-forward、自定义、Three-Way Merge
| 分支管理工作流 | 特 点 |
|---|---|
| Git Flow | 分支类型丰富，规范严格 |
| Github Flow | 规则简单，只有主干分支和开发分支 |
| Gitlab Flow | 在主干分支和开发分支之上构建环境分支，版本分支，满足不同发布或环境需要 |
3. 分支管理工作流
(1). Git Flow
是早期分支管理策略
五种类型分支
- master：主干分支
- develop：开发分支
- feature：特性分支
- release：发布分支
- hotfix：热修复分支
优点
严格按照定义的标准执行，代码将会清晰难以出现混乱
缺点
流程复杂，上线节奏慢，导致研发有一定概率不按标准执行导致代码混乱
(2). Github Flow
基于Pull Request向主干分支提交代码
团队合作方式（在owner创建仓库后）
- （第一种）其他用户通过fork的方式创建自己的仓库，并且在fork的仓库进行开发
- （第二种）统一给团队内成员分配权限，直接同一个仓库内进行开发
创建Pull Request：
- 创建main主分支
- 创建feature分支
- 创建feature到main的Pull Request
(3). Gitlab Flow
在Git Flow和Github Flow做出优化，保持了单一分支的简便，同时适应不同的开发环境
- 上游优先原则：上游分支通常是master，假如项目的成员向代码仓库提交代码，只有master分支使用者采纳才可以进入下游分支。
代码合并
- Fast-Forward：不会产生merge节点，合并后保持一个线性历史，如果target分支更新，需要rebase操作更新source branch后才可以合入。
- Three-Way Merge：三方合并，会产生一个新的merge节点
4. 选择工作流的原则
对小型团队合作，使用GitHub
- 不要一次性上传过多代码（上千行、上万行显然是行不通的），应该少量多次
- 提交Pull Request后需要保证有CR后再合入
- 主干分支要保持整洁，使用fast-forward合入方式，合入前进行rebase
