GitFlow 简介
这段时间我使用git的次数明显增多，有些时候会有很多重复的命令啥的，而且一不小心还会出问题，这个时候，我发现了 gitflow 这个强无敌的 git 扩展。
然而像我这样的英文盲看见这种文章就头疼，所以我决定写个最简单的中文介绍。
先放一张大图
这张图基本就是 gitflow 最核心的操作了。
首先，我们当然要从master开始说起
一般我们要开发一个新功能，都是从 master 开一个分支，然后在新开的分支上进行操作，有必要的话还会继续新开分支，所有更改完成之后 merge 回 master，顺便再打 Tag，这都是常规操作。然而 gitflow 特立独行，它很少在 master 上进行操作，毕竟 master 实在是太重要了，不可能随随便便进行操作。 所以，我们只要新开一个分支，这个分支拥有所有的 master 代码，我们所有的操作都是以这个 branch 为基本点，所有更新完成后，merge 回 master 不就好了吗？嗯~ o(￣▽￣)o，这是个完美的思路。鄙人认为 gitflow 的根本就在这里。尽量少的对 master 进行操作，主线永远只做第一步和最后一步，其他的都不归主线管。虽然传统的方法也可以在一定程度上体现这一点，但是我感觉 gitflow 的表达更清晰。
develop
在上一部分中，我们知道了 gitflow 的起始工作，就是开一个 branch，所有的开发工作都是在这个 branch 上进行。现在，我们就来瞅瞅这个分支。 这部分的题目是 “develop”，所以，我们的这个分支就叫 “develop”，人如其名，单从名字上我们就能看出这个分支是用来进行开发操作的了。不同于传统的操作，这个分支更像是一种形式意义上的 master，以至于我们将原来的 master 放在这个分支的位置上几乎没有什么违和感（除了为紧急的 bug 修复所开的分支）。
feature
同样的，我们也能从名字上知道这个分支是用来进行具体代码造作的，这个分支就是从 develop 分支开出来的，所有我们要实现的功能都会直接在这个分支上进行实现，功能实现完毕后 merge 到 develop。这里没什么好讲的。
release
这是一个有意思的 branch。新功能开发完成之后，我们就要合并到主线上了，使代码真正开始工作，但是问题来了：如果直接将 develop 合并到 master，那么之后的开发怎么办，重新再来一个 develop 分支吗？这样就破坏了 develop 的连续，而且跟传统的操作又有什么区别。所以，release 分支出现了。这个分支是从 develop 上出来的，将此分支 merge 到 master，然后删除这个分支。嗯~ o(￣▽￣)o，再次完美。既完成了代码上线，又保留了 develop 分支，方便后期继续以 develop 为基础开发新功能以及修复 bug。
hotfix
热修复或者紧急修复，无论是 git 还是 gitflow，一般这个分支是不会轻易用到的，一旦用到了，这个分支的优先级就是最高的。该分支启用后，将直接对 master 进行修复，这个在 git 和 gitflow 中都是一样的，是危险系数较高的操作。代码更改完成后，我们将要合并到 master ，不仅如此，我们还要将其合并到 develop 中，以保证 develop 拥有 master 的所有代码。所有操作完成，并验收通过后，可以将该分支删除，但我不认为应该马上删除，毕竟 hotfix 有可能只是一种临时救急的解决方案，源码代中肯定是有不正确的地方，应该保留一段时间，以便后期的 bug 修复。
小结
好了，主干内容差不多就是这样了。gitflow 其实就是将 git 的部分命令进行打包，方便用户使用 git。私认为 gitflow 更重要的不是在命令上，而是在于他为我们提供了一种 git 思路，特别是对于企业内的团队，这点可能很重要。
以上内容纯属个人理解，不涉及任何商业部分。保证原创，内容如有雷同，纯属巧合。