Pull Request 可以和功能分支工作流、 或 一起使用。但一个 Pull Request 要求要么分支不同要么仓库不同，所以不能用于集中式工作流。 在不同的工作流中使用 Pull Request 会有一些不同，但基本的过程是这样的：开发者在本地仓库中新建一个专门的分支开发功能。开发者 push 分支修改到公开的 Bitbucket 仓库中。开发者通过 Bitbucket 发起一个 Pull Request 。
当要发起一个 Pull Request ，你所要做的就是请求（ Request ）另一个开发者（比如项目的维护者）来 pull 你仓库中一个分支到他的仓库中。这意味着你要提供4个信息以发起 Pull Request ： 源仓库、源分支、目的仓库、目的分支。这几值多数 Bitbucket 都会设置上合适的缺省值。但取决你用的协作工作流，你的团队可能会要指定不同的值。
Pull requests 是 Bitbucket 提供的让开发者更方便地进行协作的功能，提供了友好的 Web 界面可以在提议的修改合并到正式项目之前对修改进行讨论。开发者向团队成员通知功能开发已经完成，Pull Requests 是最简单的用法。 开发者完成功能开发后，通过 Bitbucket 账号发起一个 Pull Request 。 这样让涉及这个功能的所有人知道要去做 Code Review 和合并到 master 分支。
项目维护者初始化正式仓库和任何使用 Git 项目一样，第一步是创建在服务器上一个正式仓库，让所有团队成员都可以访问到。 通常这个仓库也会作为项目维护者的公开仓库。公开仓库应该是裸仓库，不管是不是正式代码库。 所以项目维护者会运行像下面的命令来搭建正式仓库：ssh user@hostgit init --bare /path/to/repo.
所有的个人公开仓库实际上只是为了方便和其它的开发者共享分支。各个开发者应该用分支隔离各个功能，就像在功能分支工作流和 一样。 唯一的区别是这些分支被共享了。在 Forking 工作流中这些分支会被 pull 到另一个开发者的本地仓库中，而在功能分支工作流和 Gitflow 工作流中是直接被 push 到正式仓库中。
在 Forking 工作流中，『官方』仓库的叫法只是一个约定，理解这点很重要。 从技术上来看，各个开发者仓库和正式仓库在 Git 看来没有任何区别。 事实上，让正式仓库之所以正式的唯一原因是它是项目维护者的公开仓库。
和其它的 Git 工作流一样，Forking 工作流要先有一个公开的正式仓库存储在服务器上。 但一个新的开发者想要在项目上工作时，不是直接从正式仓库克隆，而是 fork 正式项目在服务器上创建一个拷贝。这个仓库拷贝作为他个人公开仓库 ——其它开发者不允许 push 到这个仓库，但可以 pull 到修改（后面我们很快就会看这点很重要）。
Forking 工作流是分布式工作流，充分利用了 Git 在分支和克隆上的优势。可以安全可靠地管理大团队的开发者（ developer ），并能接受不信任贡献者（ contributor ）的提交。Forking 工作流和前面讨论的几种工作流有根本的不同，这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。
下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。创建开发分支第一步为 master 分支配套一个 develop 分支。简单来做可以本地创建一个空的 develop 分支， push 到服务器上：git branch developgit push -u origin develop以后这个分支将会包含了项目的全部历史，而 master 分支将只包含了部分历史。
维护分支或说是热修复（ 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 个分支的区别展开。
Gitflow 工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并 push 分支到要中央仓库中。
Gitflow 工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。这节介绍的 Gitflow工作流 借鉴自在 nvie的 Vincent Driessen 。Gitflow 工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。
下面的示例演示了如何把 Pull Requests 作为 Code Review 的方式，但注意 Pull Requests 可以用于很多其它的目的。小红开始开发一个新功能在开始开发功能前，小红需要一个独立的分支。使用下面的命令新建一个分支：git checkout -b marys-feature master这个命令检出一个基于 master 名为 marys-feature 的分支， Git 的 -b 选项表示如果分支还不存在则新建分支。
功能分支除了可以隔离功能的开发，也使得通过 讨论变更成为可能。一旦某个开发完成一个功能，不是立即合并到 master，而是 push 到中央仓库的功能分支上并发起一个 Pull Request 请求去合并修改到 master 。在修改成为主干代码前，这让其它的开发者有机会先去 Review 变更。Code Review 是 Pull Requests 的一个重要的收益，但 Pull Requests 目的是讨论代码一个通用方式。
功能分支工作流仍然用中央仓库，并且 master 分支还是代表了正式项目的历史。但不是直接提交本地历史到各自的本地 master 分支，开发者每次在开始新功能前先创建一个新分支。功能分支应该有个有描述性的名字，比如 animated-menu-items 或 issue-#1061 ，这样可以让分支有个清楚且高聚焦的用途。
功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个专门的分支来开发。这样可以在把新功能集成到正式项目前，用 Pull Requests 的方式讨论变更。一旦你玩转了集中式工作流，在开发过程中可以很简单地加上功能分支，用来鼓励开发者之间协作和简化交流。功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在 master 分支上。
让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红，看他们是如何开发自己的功能并提交到中央仓库上的。有人先初始化好中央仓库第一步，有人在服务器上创建好中央仓库。如果是新项目，你可以初始化一个空仓库；否则你要导入已有的 Git 或 SVN 仓库。
关注时代Java
