Gitflow工作流简介
Gitflow工作流通过为功能开发、发布准备和项目维护分配独立的分支，让发布迭代过程更流畅。
Gitflow工作流定义了一个围绕项目发布的严格分支模型，它会相对复杂一点，但提供了用于一个健壮的用于管理大型项目的框架，非常适合用来管理大型项目的发布和维护。 贯穿整个开发周期，master和develop分支是一直存在的，master分支可以被视为稳定的分支， 而develop分支是相对稳定的分支，特性开发会在feature分支上进行，发布会在release分支上进行，而bug修复则会在hotfix分支上进行，这样也有效避免了不同类型的开发工作在代码层级的耦合和干扰。
1、历史分支
Gitflow工作流使用2个分支来记录项目的历史。 master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。
2、功能分支
每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。 当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。
3、发布分支
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上，这个分支只应该做Bug修复、文档生成和其它面向发布的任务。 一旦对外发布的工作都完成了， 发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。
4、维护分支
维护分支或说是热修复（hotfix）分支用于快速给产品发布版本（production releases）打补丁， 这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
如果你没有认识到这个工作流很有用，那可能是因为你的开发工作还没有复杂到一个程度，一个必须要规避代码干扰、保证并行推进的程度。