1. 为什么讲 git 代码管理？
看到网上教程，大部分是从细节上讲 git 操作，而不是从宏观层面上认识 git 是如何代码管理。
2. git 代码管理4条准则或4个问题
- 明确分支种类、数目、角色。
- 明确代码发布流程（具体到发布分支是什么、发布前如何合并代码）。
- 明确测试阶段 bug 修复流程（具体到 qa 和开发之间代码分支隔离）。
- 明确生产 bug 修复流程。
Git代码管理好不好，就看四个问题解决了没！！！
3. git 分支模型
- github flow
- git flow
- gitlab flow
- 其他分支模型——chunk-base-model
前 3 种是主流，后面一种是非主流分支模型。
3.1 github flow 分支模型
特点：简单，新的 featrue/hofix/update 只能串行执行。 应用场景：只能适用于小规模的开发，如：js库。
3.2 git flow 分支模型
特点：复杂，新功能可以并行开发。
应用场景：适用于较大web系统应用的开发，如：某个后管系统。 通俗来讲：开发的应用功能迭代快，团队人多且每个人技术背景差异大，特别适合这种分支模型。
git flow 分支角色说明
master 用于存储发布后的代码。 develop 用于保证开发时，代码是最新。 release 用于测试和开发之间的代码缓冲和发布。 feature 用于开发新的功能和测试阶段bug修复。 hotfix 用于修复生产bug。 另外，分支的角色，也不是一层不变，有时更具情况做响应的调整的。
git flow 分支模型的 develop 问题
develop 分支是保证代码最新，往往有这么一个情况，feature 分支 merge 到 develop ， 该 feature 上功能突然不上， develop 就超出当前需求开发的“最新”。解决方案有3种：
- 利用代码回滚或cherry-pick等去回到当前迭代“最新”的代码，需要开发（我好难啊o_0 ）知晓别开发者的 commit 对应的代码。
- 投入更多人力管理 develop 分支，让分支管理者（我好难啊o_0）知晓合到 develop 的每个 feature 迭代情况，超出的禁止合到 develop 上。
- 用 realese/feature/hotfix 代替 develop，保证迭代初代码是最新的。(大家都舒服^_^）
git flow 分支模型的hotfix问题
问题：假设出现一个hotfix 的 bug，由于需求迭代或项目重构，这个 hotfix 的 bug 可能不需fix？不然发现，一个代码管理问题就变成项目管理问题。 解决方案：
- 如果是紧急发布，那么修改之后，通过测试，将 hotfix 分支合到主干分支后，要通知在该仓库下正在开发需求的开发人员，拉最新的代码。
- 常规需求发布，在合并到release分支上，需要注意冲突。 补充：hotfix 分支 merge 到 develop 分支不优雅，尤其项目重构时，merge 会出现很多问，这情况用 cherry-pick 就好很多。
cherry pick 是什么？
屏幕快照 2020-03-09 下午10.32.35
3、gitlab flow 流程
团队内，增加 1 个开发代码和测试代码的缓冲。
团队内 + 团队外，增加两个开发代码和测试代码的缓冲。
特点：中庸，比 github flow 复杂，比 gitflow 简单。 应用场景：适用于较大web等系统应用的开发，人员简单，或者，人多但人员技术级别都很高。
4、其他分支模型——chunk-base-model
这种分支模型，适用于开发基础建设好，团对人员都强的人，我们就看看就好！
总结
1、所有分支模型都一个主干分支，然后有一个分支，用于测试和开发之间代码缓冲。
2、所有分支的命名、commit 信息需要一个规范，这样才能保证有效管理分支。例如：分支的命名 feature/1.0.0_20200124_feat1，release/1.0.0_20200124等。
3、最主流的分支模型是 gitflow 分支模型，但是，没有哪个分支模型是最好，只有最适合自己团队的分支模型。
