Gitflow 工作流和功能分支工作流类似，但围绕项目发布定义一个严格的分支模型。 在 Gitflow 工作流中使用 Pull Request 让开发者在发布分支或是维护分支上工作时，可以有个方便的地方对关于发布分支或是维护分支的问题进行交流。
功能分支工作流用一个共享的 Bitbucket 仓库来管理协作，开发者在专门的分支上开发功能。 但不是立即合并到 master 分支上，而是在合并到主代码库之前开发者应该开一个 Pull Request 发起功能的讨论。功能分支工作流只有一个公开的仓库，所以 Pull Request 的目的仓库和源仓库总是同一个。 通常开发者会指定他的功能分支作为源分支，master 分支作为目的分支。
当要发起一个 Pull Request ，你所要做的就是请求（ Request ）另一个开发者（比如项目的维护者）来 pull 你仓库中一个分支到他的仓库中。这意味着你要提供4个信息以发起 Pull Request ： 源仓库、源分支、目的仓库、目的分支。这几值多数 Bitbucket 都会设置上合适的缺省值。但取决你用的协作工作流，你的团队可能会要指定不同的值。
Pull requests 是 Bitbucket 提供的让开发者更方便地进行协作的功能，提供了友好的 Web 界面可以在提议的修改合并到正式项目之前对修改进行讨论。开发者向团队成员通知功能开发已经完成，Pull Requests 是最简单的用法。 开发者完成功能开发后，通过 Bitbucket 账号发起一个 Pull Request 。 这样让涉及这个功能的所有人知道要去做 Code Review 和合并到 master 分支。
所有的个人公开仓库实际上只是为了方便和其它的开发者共享分支。各个开发者应该用分支隔离各个功能，就像在功能分支工作流和 一样。 唯一的区别是这些分支被共享了。在 Forking 工作流中这些分支会被 pull 到另一个开发者的本地仓库中，而在功能分支工作流和 Gitflow 工作流中是直接被 push 到正式仓库中。
在 Forking 工作流中，『官方』仓库的叫法只是一个约定，理解这点很重要。 从技术上来看，各个开发者仓库和正式仓库在 Git 看来没有任何区别。 事实上，让正式仓库之所以正式的唯一原因是它是项目维护者的公开仓库。
维护分支或说是热修复（ hotfix ）分支用于生成快速给产品发布版本（ production releases ）打补丁，这是唯一可以直接从 master 分支 fork 出来的分支。 修复完成，修改应该马上合并回 master 分支和 develop 分支（当前的发布分支），master 分支应该用新的版本号打好 Tag 。为 Bug 修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
一旦 develop 分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从 develop 分支上 fork 一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做 Bug 修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到 master 分支并分配一个版本号打好 Tag 。
每个新功能位于一个自己的分支，这样可以 push到中央仓库以备份和协作。 但功能分支不是从 master 分支上拉出新分支，而是使用 develop 分支作为父分支。当新功能完成时，合并回 develop 分支。 新功能提交应该从不直接与 master 分支交互。注意，从各种含义和目的上来看，功能分支加上 develop 分支就是功能分支工作流的用法。但 Gitflow 工作流没有在这里止步。
相对使用仅有的一个 master 分支，Gitflow 工作流使用 2 个分支来记录项目的历史。master 分支存储了正式发布的历史，而develop 分支作为功能的集成分支。这样也方便 master 分支上的所有提交分配一个版本号。 剩下要说明的问题围绕着这 2 个分支的区别展开。
功能分支除了可以隔离功能的开发，也使得通过 讨论变更成为可能。一旦某个开发完成一个功能，不是立即合并到 master，而是 push 到中央仓库的功能分支上并发起一个 Pull Request 请求去合并修改到 master 。在修改成为主干代码前，这让其它的开发者有机会先去 Review 变更。Code Review 是 Pull Requests 的一个重要的收益，但 Pull Requests 目的是讨论代码一个通用方式。
功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个专门的分支来开发。这样可以在把新功能集成到正式项目前，用 Pull Requests 的方式讨论变更。一旦你玩转了集中式工作流，在开发过程中可以很简单地加上功能分支，用来鼓励开发者之间协作和简化交流。功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在 master 分支上。
中央仓库代表了正式项目，所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧，Git 会拒绝 push 提交否则会覆盖已经在中央库的正式提交。 在开发者提交自己功能修改到中央库前，需要先 fetch 在中央库的新增提交，rebase 自己提交到中央库提交历史之上。 这样做的意思是在说，『 我要把自己的修改加到别人已经完成的修改上。
Git 工作流学习指南
关注时代Java
