下面的示例演示了 Pull Request 如何在在 Forking 工作流中使用。
也同样适用于小团队的开发协作和第三方开发者向开源项目的贡献。
在示例中，小红是个开发，小明是项目维护者。他们各自有一个公开的 Bitbucket 仓库，而小明的仓库包含了正式工程。
小红 fork 正式项目
小红先要 fork 小明的 Bitbucket 仓库，开始项目的开发。她登陆 Bitbucket ，浏览到小明的仓库页面，
点 Fork 按钮。
然后为 fork 出来的仓库填写名字和描述，这样小红就有了服务端的项目拷贝了。
小红克隆她的 Bitbucket 仓库
下一步，小红克隆自己刚才 fork 出来的 Bitbucket 仓库，以在本机上准备出工作拷贝。命令如下：
git clone https://user@bitbucket.org/user/repo.git请记住，git clone 会自动创建 origin 远程别名，是指向小红 fork 出来的仓库。
小红开发新功能
在开始改代码前，小红要为新功能先新建一个新分支。她会用这个分支作为 Pull Request 的源分支。
git checkout -b some-feature
# 编辑代码
git commit -a -m "Add first draft of some feature"在新功能分支上，小红按需要添加提交。甚至如果小红觉得功能分支上的提交历史太乱了，她可以用交互式 rebase 来删除或压制提交。
对于大型项目，整理功能分支的历史可以让项目维护者更容易看出在 Pull Request 中做了什么内容。
小红 push 功能到她的 Bitbucket 仓库中
小红完成了功能后，push 功能到她自己的 Bitbucket 仓库中（不是正式仓库），用下面简单的命令：
git push origin some-branch这时她的变更可以让项目维护者看到了（或者任何想要看的协作者）。
小红发起 Pull Request
Bitbucket 上有了她的功能分支后，小红可以用她的 Bitbucket 账号浏览到她的 fork 出来的仓库页面，
点右上角的【 Pull Request 】按钮，发起一个 Pull Request 。
弹出的表单自动设置小红的仓库为源仓库，询问小红以指定源分支、目标仓库和目标分支。
小红想要合并功能到正式仓库，所以源分支是她的功能分支，目标仓库是小明的公开仓库，
而目标分支是 master 分支。另外，小红需要提供 Pull Request 的标题和描述信息。
如果需要小明以外的人审核批准代码，她可以把这些人填在【 Reviewers 】文本框中。
创建好了 Pull Request ，通知会通过 Bitbucket 系统消息或邮件（可选）发给小明。
小明 review Pull Request
在小明的 Bitbucket 仓库页面的【 Pull Request 】Tab 可以看到所有人发起的 Pull Request 。
点击小红的 Pull Request 会显示出 Pull Request 的描述、功能的提交历史和每个变更的差异（ diff ）。
如果小明想要合并到项目中，只要点一下【 Merge 】按钮，就可以同意 Pull Request 并合并到 master 分支。
但如果像这个示例中一样小明发现了在小红的代码中的一个小 Bug ，要小红在合并前修复。
小明可以在整个 Pull Request 上加上评注，或是选择历史中的某个提交加上评注。
