目录

一、工作流介绍

1.1 什么是工作流

1.2 两种工作流对比

二、Git Flow 工作流介绍

2.1 项目分支

2.2 开发流程

2.2.1 日常开发

2.2.2 代码提交

2.2.3 项目发布

2.2.4 项目测试和项目热修复

---

一、工作流介绍

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 分支。这样的好处在于可以避免开发分支的代码污染。