本篇为下篇，介绍git flow
目录下篇
Git Flow
在使用git时，团队中需要制定统一的工作流程，也就是git flow，避免在开发过程中出现混乱的git版本。混乱的git版本会对开发带来很多不必要的麻烦，诸如代码丢失，生产环境错误。
目前主流的git flow模型是由 [Vincent Driessen](https://nvie.com/posts/a-successful-git-branching-model/)提出的，适合于按需求有计划性的进行项目发布，同时定义了master, release, develop, feature, hotfix这几种分支类型，赋予了他们相应的职责概念。各位可以翻阅原文和相关译文进行了解，本篇教程在此模型基础上做了一些删减和修改，仅保留了以下分支类型，并修改了一些概念。
分支类型和概念
-
master，用于发布生产环境的分支，该分支上的代码必须是测试通过的代码，只接受来自于feature和hotfix的分支合并每次发布需要进行tag标记以便于出错时进行回滚。 -
develop，测试分支，所有feature分支开发完毕的功能需要合并到develop进行测试后才能合并到master。develop可能会存在多个。develop不能合并到master。 -
feature，开发分支。 -
hotfix，紧急修复分支，在master分支出现BUG需要进行紧急修复时使用。
流程规范
先来看下图，这里展示了在当前4种分支类型下我们进行的工作流。
master和develop
在之前我们简单介绍过，master是用于发布的分支，因此需要与生产环境保持绝对一致，不能出现直接提交的情况。在每次master发布上线时，我们需要继续tag标记，万一生产环境出现紧急问题可以迅速通过tag进行版本回滚。
develop是用于测试的分支，可能在一个develop分支种存在多个来自于feature的开发功能，因此不能直接从develop合并到master上，避免出现将未测试通过的功能偷跑上线的情况发生。一般一个develop分支对应一个测试环境，根据团队进行可以部署多个测试环境和多个develop分支。
master和develop分支通常不允许出现直接在进行commit和push操作，也就是直接这些分支上提交代码，这些分支只能通过merge进行修改。这些限定在大部分git平台上均有实现，通过设定为保护分支可以防止被删除，通过权限设置可以只允许部分人员进行push操作。
feature
这个分支是开发者最常用到的分支之一，在接到新的功能需求时，feature需要从当前最新的master切出分支来进行开发。多个feature之间是互相独立的，因此也会存在代码冲突的情况，这就需要各位开发人员互相的协调合作了。这里说明以下feature的操作流程。
- 有新需求，从最新的
master上切出分支，进行功能开发。 - 在
feature上开发完毕功能后，需要先merge到develop分支进行测试。在合并之前，需要将最新的master合并到当前分支来，确保不会有生产环境的功能遗漏而导致测试不通过的情况。 - 测试人员在
develop上出现问题，由开发人员在feature上进行修复后，重新操作步骤2发布到测试。 - 测试通过，
merge到master进行上线。 - 上线完毕，删除
feature分支。
这便是feature的整个生命周期，这里有人可能有疑惑，如果上线后出现BUG要怎么办呢？别着急，马上我们就来讲讲hotfix。
hotfix
一旦feature发布到生产环境后出现BUG需要紧急修复，但是feature的职责其实在merge到master时就已经终结了，现在我们需要的一个补救分支hotfix。
hotfix就如同名字一样，用于生产环境的快速修复，一旦生产环境出现问题。
- 首先我们要将版本进行回滚。
- 然后立刻切出
hotfix，进行问题排查和修复。 - 在修复完毕后同样需要进入到
develop进行测试，千万不要盲目的自信上线。 - 在测试通过之后，
merge到master进行上线。 - 上线完毕，删除
hotfix分支。
不过要是这次上线完了还有问题，那就再来一个hotfix！
总结
本次给大家介绍了一下git flow的基本概念和情况，这里需要强调的是，git flow是一种规范，本期的git flow只是基于我个人对工作流的理解和应用，希望能对你有所帮助和启发。
不同的团队会存在不同的情况，并且团队慢慢发展，不存在说有一个固定且一成不变，并能够完美适用当下情况的git flow规范。一旦当前的git flow规范开始成为团队开发的绊脚石，就要考虑进行相应的改良。