在 Forking 工作流中，开发者 push 完成的功能到他自己的仓库中，而不是共享仓库。 然后，他发起一个 Pull Request ，让项目维护者知道他的功能已经可以 Review 了。在这个工作流，Pull Request 的通知功能非常有用，因为项目维护者不可能知道其它开发者在他们自己的仓库添加了提交。由于各个开发有自己的公开仓库，Pull Request 的源仓库和目标仓库不是同一个。
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 分支。
功能分支除了可以隔离功能的开发，也使得通过 讨论变更成为可能。一旦某个开发完成一个功能，不是立即合并到 master，而是 push 到中央仓库的功能分支上并发起一个 Pull Request 请求去合并修改到 master 。在修改成为主干代码前，这让其它的开发者有机会先去 Review 变更。Code Review 是 Pull Requests 的一个重要的收益，但 Pull Requests 目的是讨论代码一个通用方式。
关注时代Java
