玩转 Git（三） GitFlow 工作流详解
目录
一、工作流介绍
1.1 什么是工作流
在多人协同开发中，如果每个人都拥有直接推送代码到远端分支的权限，由于个人技术水平或粗心，可能会将低质量或是错误的代码直接更新到远端分支上，甚至可能由于开发人员的误操作，导致代码缺失的情况。这时候，就要制定一个合理的使用 Git 进行多人协同开发的流程，大家共同遵守这个流程开发，并辅以 Git 权限控制，实现安全的代码迭代和管理，因此工作流就出现了。
1.2 两种工作流对比
| Git Flow | GitHub Flow | |
| 适用场景 | 团队协作 | 个人简单开发 |
| 复杂度 | 复杂 | 简单高效 |
| 安全性 | 具备审核环节，安全性高，能够阻止低质量代码或错误代码的提交 | 个人可以直接推送，安全性较低，取决于个人的技术水平和细心程度 |
| 简述 | 有多条分支维护多种情况 | 只有主线 master 分支，在产品和开发进度不一致时会增加一个 production 分支 |
二、Git Flow 工作流介绍
2.1 项目分支
master 分支：
正式发布分支，用于存储正式发布到线上的版本代码，要保证这个分支的代码是随时正确可用的。master代码应只合并 release 分支的代码，并在提交时不应将其他分支合并进来。若线上发现问题要修改，应发布新的版本，即对应新的 master 节点。
dev 分支：
developer 开发分支，这个分支是操作最频繁的分支，多人合作时应定期将自己的可用代码合并到dev分支，以便其他合作者更新。
dev_xxxx：
每个人应以dev_tom(名字)或dev_newWork(工作任务)新建基于dev的分支，并在这个分支上做开发。
release 分支：
存储即将上线的版本代码，例如：2020.03.02要上线正式代码，就可以建一个release_0302的分支，存储即将发布的项目。若测试环节中出现错误，则开发者需要建立基于这个release的hotFix分支，进行修改代码。在代码正常运行一段时间后，
hotFix 分支：
热修复分支，用于修复release测出的bug。当修复完毕后，需要将这个分支合并到release以及 dev。这样的好处在于，不会影响其他开发进度，开发者可以一部分修复测试出的bug，另一部分按照原来的开发进度，开发dev分支。在修复完bug后，记得把release分支并回dev，用以更新bug。
2.2 开发流程
2.2.1 日常开发
日常开发过程中，在初始化项目后，需要创建一条基于 master 分支的发展分支 dev，团队开发人员在开发时，应创建自己个人的基于 dev 发展分支的独立分支，以 dev_xxx 命名，处理代码
2.2.2 代码提交
开发者提交：
开发者开发完毕项目时，应提交自己的代码到自己个人的远端分支上，并提交合并请求
填写相关修改信息，并选择要合并到的目标分支
代码审核：
管理人员审核合并请求，若代码审核通过，则合并
2.2.3 项目发布
当开发进行到一定阶段，需要发布项目到正式服务器。这时候就需要 release 分支起作用了。
例如：当前有一个项目要在 2019.05.20 发布，今天是2019.05.10，项目需要提交给测试，这时候你会面临一个问题：
项目要持续进行开发，如何保存要发布的这个版本的代码？
- 若直接存放在 dev 分支下，则会导致准备发布的代码被后续开发的代码污染
- 若存放到 master 分支下，则无法保证这次要发布的代码没问题，违背了 master 分支下代码必须是正常可用的
故需要新建一个分支，保存即将发布的代码，这就是 release 分支的作用。release 分支应在项目正常运行一段时间后删除，保证分支树的干净。
2.2.4 项目测试和项目热修复
存放到 release 上的版本在进入测试阶段或是已经发布后，可能发现存在 bug，要进行修复，这时候应该建立基于这个 release 版本的 hotfix 分支。这样的好处在于可以避免开发分支的代码污染。