Git-Flow浅析
参与过项目开发的同学们对Git应该都不会陌生，Git作为一个强大的版本控制工具，从诞生起就一直在帮助开发人员更好的协同工作，改善开发效率。还记得大概两年前的样子，公司项目代码提出往Git上迁移的时候，有同学反映这不是杀鸡用牛刀么！但是事实证明，用牛刀杀鸡绝对很过瘾。正如题目所言，这篇文章我们着重说明下Git Flow的流程和使用
问题的提出
在说明Git Flow之前我们先来回顾下在没有使用Git Flow时我们面临的问题，这里我大概总结下我在项目中碰到的部分
- 开发分支不明确，很多开发者直接在
master 上进行开发,这样直接丧失了Git的权限管理功能 - 开发人员随意拉分支，导致Git仓库无限混乱
- 开发分支、发布分支经常是一个，不利于项目代码的良性发展
- 各个分支的修改不能同步到开发、生产分支
风险很大
类似上述的问题还有很多，所以为了避免上述问题引发的悲剧，Git Flow产生了
Git Flow是什么
Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
一般而言，软件开发模型有常见的瀑布模型、迭代开发模型、以及最近出现的敏捷开发模型等不同的模型。每种模型有各自应用场景。Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题。因此，Git flow可以很好的于各种现有开发模型相结合使用。
如下图所示(引自nvie的博文)
Git Flow各个分支
master
master分支是我们的主分支，也常被我们用做生产分支。master和其他分支不同，任何对master分支的修改都必须有master权限才可以。我们在其他分支做的任何改变或者说发布最终都要合并至master分支
develop分支
develop分支是我们的开发分支，随着开发时间的发展，develop分支也是一直在发展的。同时，如果我们有新的功能模块需要开发，则可以根据develop分支来建立我们的功能模块，或者当我们的develop分支成熟后从develop分支衍生发布分支等。develop是作为我们的开发主线存在的，所以的开发工作必须和develop有关或者间接有关
feature
featrue是我们的功能点，通常情况下，我们按照功能模块从develop分支分出featrue分支，当feature分支开发完成后，需要及时的合并至develop分支。
举个不太恰当的例子，就是小朋友和爸比出去完，当小朋友有去买糖的同时，爸比还在不断的往前走，小朋友自己买完后需要及时和爸比会和
hotfix
hotfix，顾名思义，就是我的修复分支。当我们的产品发布后，发现有bug的存在这时就需要用到hotfix分支。通常，hotfix分支从master分子分出，当我们修复完成后，需要同步至develop分支，因为develop分支还在持续的开发中。随着下一版本发布修复。如果存在多个develop分支的话，则需要同步至多个develop分支，当然，理论上不会存在这种情况
release分支
发布分支，当我们的develop分支已经开发完成后，从develop分支完成至release分支。在release分支阶段只允许bugfix，不可做功能性开发，修复bug的部分代码需要及时合并至develop分支。发布后需要将release分支合并至master
关于Git Flow 常用的大概也就这么多内容，重要的不是工具或者方法而是我们遵从项目规范的意愿！