4、GitFlow 工作流(最流行)
Gitflow工作流没有用超出上面功能分支工作流的概念和命令，而是为不同的分支，分配一个很明确的角色，并定义分支之间如何交互，和什么时候进行交互。
-
除了有master主分支（用于存储正式发布的历史版本）外，还有一个作为功能集成分支的develop分支。
当初始化完成后，某个程序员想要开发一个功能，并不是直接从master分支上拉出新分支，而是使用develop分支作为父分支来拉出新分支。
当新功能完成后，再合并回父分支，新功能的提交并不与master分支直接交互。
-
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。
新建的发布分支用于开始发布循环，所以从这个时间点开始之后新的功能，不能再加到这个分支上，该分支只应该做Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了，发布分支合并到master分支，并分配一个版本号打好Tag。
另外，这些从新建发布分支以来的做的修改，要合并回develop分支上。
-
维护分支或说是热修复（hotfix）分支用于，快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。
修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支，让团队可以快速处理掉问题，而不用打断其它工作或是等待下一个发布循环。
你可以把维护分支想成是一个直接在master分支上处理的临时发布。
总结就是：Gitflow 工作流通过为功能开发、发布准备和维护设立了独立的分支，让发布迭代过程更流畅，充分的利用了分支的特点。严格的分支模型也为大型项目提供了一些非常必要的结构。
下图是完整的Gitflow 工作流开发方式图，但实际开发工作环境可能会精简：
Gitflow工作流总结：
适用人群：任何开发团队，熟悉Git分支的团队。
-
工作方式：
- 项目维护者创建项目维护者的远程仓库，创建master分支与develop分支，贡献者可读不可写。
- 每个贡献者
git clone远程仓库中的develop分支到本地仓库。（记住，develop分支相当于master的分支，包括功能开发，修改，测试。master分支相当于最终分支） - 每个贡献者在本地仓库创建自己的feature分支，在feature分支上开发。
- 在feature分支又可以创建多个feature分支，继续开发项目。
- 每个贡献者每次开发完成就
git commit到本地仓库中自己的feature分支， 接着git push到远程仓库。 - 通过
pull request提醒项目维护者，浏览贡献者提交feature分支。 - 项目维护者把feature分支拉下来，然后合并到自己本地仓库的develop分支上测试。
- 组长测试feature分支通过之后，由组长负责把feature分支合并到远程仓库的develop分支上。
- 项目维护者会release分支上
git tag打上版本号。 - 项目维护者可以从develop分支创建release分支，接着把release分支合并到master分支上，同时master分支同步到develop分支。
- 项目维护者在远程仓库把合并过的feature分支删除。
- 每个贡献者在本地仓库把合并过的feature分支删除。
- 每个贡献者将本地仓库分支切换为develop分支，然后
git pull将本地仓库的master分支更新到远程仓库的develop分支版本。
PS：Gitflow工作流是
Vincent Driessen工程师提出的多分支工作流。
5、Forking 工作流(偶尔使用)
分叉(Forking)工作流也可以叫做分布式工作流，是在 GitFlow工作流的基础上的衍生，充分利用了Git在分支和克隆上的优势，再加上pull request 的功能，以达到代码审核的目的。既可以管理大团队的开发者（developer）的提交，也可以接受不信任贡献者（contributor）的提交。
这种工作流使得每个开发者都有一个服务端仓库（此仓库只有自己可以push推送，但是所有人都可以pull拉取修改），每个程序员都push代码到自己的服务端仓库，但不能push到正式仓库，只有项目维护者才能push到正式仓库，这样项目维护者可以接受任何开发者的提交，但无需给他正式代码库的写权限。
这种工作流适合开源社区的开源项目，大家统一对项目做贡献，但是有一个人或一个团队作为开发者来管理项目，所有的贡献者的代码由开发者审核，其功能完善之后再由开发者push到正式仓库中。
总结：
- 分叉(Forking)工作流更适合安全可靠地管理大团队的开发者，而且能接受不信任贡献者的提交。
- 在实际工作中，如果偶尔有需要团队外的成员帮我们解决问题时，可能会用到。
- 这种工作流程并不常用，只有当项目极为庞杂，或者需要多级别管理时，才会体现出优势。 利用这种方式，项目总负责人（即主管）可以把大量分散的集成工作，委托给不同的小组负责人分别处理，然后在不同时刻将大块的代码子集统筹起来，用于之后的整合。
提示：
- 每个成员都可以从中央版本库中拉取代码。
- 每级成员都只能向上一级提交代码。
- 上一级合并代码之后继续向上级提交代码。
- 最后只有独裁者才能向中央版本库提交代码。
分叉工作流（分布式仓库工作流）总结：
适用人群：大型开发团队，熟悉Git分支的团队。
-
工作方式：
主项目维护者创建远程仓库，创建一个master分支，从项目维护者可读不可写。
从项目维护者通过fork主项目维护者的远程仓库的副本，到自己的远程仓库，包括master分支。（记住，从项目维护者的远程仓库独立于主项目维护者的远程仓库）
从项目维护者
git clone主项目维护者的远程仓库的副本到本地仓库。从项目维护者创建自己的feature分支，在feature分支上开发。
从项目维护者每次开发完成就
git commit到本地仓库中自己的feature分支， 接着git push到远程仓库。通过
pull request命令，从项目维护者合并自己feature分支，到从项目维护者的远程仓库的master分支上。从项目维护者在远程仓库把合并过的feature分支删除。
从项目维护者在本地仓库把合并过的feature分支删除。
从项目维护者在远程仓库通过
pull request向主项目维护者的远程仓库的推送。主项目维护者通过
pull request获取从项目维护者的远程仓库的推送。主项目维护者进行从项目维护者的远程仓库代码审查，测试。
主项目维护者确认无误后，可以直接合并到主项目维护者的远程仓库。
6、总结
上面介绍了在Git分布式系统中经常使用的工作流程，但是在实际的开发中，你会遇到许多可能适合你的特定工作流程的变种，你可以按照实际的情况，灵活的进行组合和拓展。
参考：
