【Git版本管理】-Git Flow版本管理

1. Git Flow介绍
介绍Git Flow我们先要对Git有一定的实践经验，如了解Git的优势：分布式存储，优秀的分支模型，快速的分支合并及拉取等，以及Git的的相关操作：创建仓库，拉取代码，创建分支，分支合并等操作。
Git Flow是对我们日常Git分支操作的封装是基于git tag装出来的代码分支管理模型。将日常的开发划分为：master，develop，release，feature，hotfixs几种版本管理场景。其中master，develop为常驻分支，release，feature，hotfixs为临时分支。
下面对上述五种分支分别介绍下：
master分支
master 分支始终是最稳定的代码分支，我们每一次迭代开发完后发布到正式场版本的代码分支，一个项目的master 分支只能有一个。在我们使用过程中master分支只有管理有权限进行merge和push，禁止在master分支进行代码修改。
develop分支
develop（功能的集成分支）分支是每次迭代版本的共有开发分支，从最新的master分支派生（管理员操作）。
每一次的需求迭代开发都是从这个develop 分支上来拉一个新的feature 分支来进行开发。
develop分支上的代码已实现了软件需求说明书中所有的功能，派生出release分支（管理员操作）。
feature分支
feature 分支是每一次需求迭代开发的分支，可以基于develop创建多个feature分支（类似于我们现在的开发分支），当测试完成后将feature分支合并至develop。
release分支
release 分支类似于预生产的分支，当我们的一个迭代的需求开发完成后，开发分支 feature 已经合并回了 develop 分支上后，我们需要拉取 release 分支。
hotfixes分支
在master分支发现bug时，在master的分支上派生出一个hotfixes分支，修改完成后，合并至master分支以及develop分支。
Git Flow版本管理流程图如下：

2. Git Flow的不足
Git Flow只适合于线性开发流程中，像我们日常多分支开发时以下场景在Git Flow中是没有完美的解决方案：
1).若多个feature分支合并到develop分支后，出现问题后如何回滚？
2).develop合并到release分支后若产品告知某个分支不上线了如何解决？
3.Git Flow流程优化
为解决上述两个问题我们对Git Flow流程做了如下优化：

上图中我们新增了uat分支（uat分支为我们的测试分支），所有的feature分支会先合并至uat分支，当测试没有问题达到预上线条件后我们将feature合并至develop分支（也可以用uat合并）。
当需要上线时我们基于develop新建release分支，此时如果发现还有问题我们可以在release分支进行修复。完成后我们将release合并至master及develop。
优化的流程图可以解决Git Flow如下问题：

• git flow中feature分支合并至develop后，feature分支就失效了，再到分支上修改将无法合并到develop（采用sourcetree管理时若合并无冲突默认会删除feature分支），此时若在需修改只能重新拉取分支，但如果有多个feature同时合并至develop了，此时拉取分支将不是线上的分支。新增uat分支优点是当feature合并至uat时feature将不会失效。
• 测试人员基于uat分支进行测试，可以将多个feature合并测试，若我们需要将某个分支uat清除掉也可以很方便实现。

下一篇 我们将详细介绍git flow版本管理工具sourcetree常用操作，多分支并行开发回滚，遴选、如何新建uat分支，如何合并feature至uat分支。