Git flow是最早诞生、并得到广泛采用的一种协作流程，多年的广泛使用证实了该协作模式成功的设计。采用功能驱动的方式，在需求的基础上创建功能分支，开发完成后，该分支合并到主分支。为不同的分支分配明确的职责，并定义分支之间如何和何时进行交互。下面结合图看各个分支的交互关系：
2个长期分支：
- master（主分支）
- develop （开发分支）
3个短期分支：
- feature branch（功能分支）
- hotfix branch（补丁分支）
- release branch（发布分支）
历史分支：
Gitflow流程使用2个分支来记录历史提交。master主分支存储正式发布的历史，每个版本用tag标注。用develop分支作为主开发分支，存储了开发的历史记录。
功能分支：
当某个开发人员需要开发新的功能时，从develop分支上拉出属于自己的新分支——feature分支。当功能开发完成，merge到develop分支。功能分支不直接与master分支交互。
发布分支：
当develop分支开发的功能稳定完善，通过各种测试，要发布新版本，就从develop分支上拉取一个发布分支——release分支，作为稳定功能版。从此时开始，新的功能就不能再加上release分支上，该分支只能做处理bug，编写文档的任务。一旦对外发布完成，发布分支要合并到master分支并分配一个版本号，打上tag。然后将release作出的改动合并给develop分支，记录在主开发分支上。
维护分支：
维护分支——hotfix分支用于给发布版本打补丁，用于快速处理临时棘手的bug，这是唯一可以直接从master分支拉取出来的分支。修复完成，改动应该立即合并到master和develop分支上，作为新版本进行发布。这样也不会直接影响develop开发分支的工作。