update pull-request draft

git-workflows-and-tutorials/pull-request.md

@@ -35,7 +35,7 @@
 :beer: 工作方式
 ---------------------
 
-`Pull Request`和[功能分支工作流](workflow-feature-branch.md)、[`Gitflow`工作流](workflow-gitflow.md)或[`Forking`工作流](workflow-forking.md)一起使用。
+`Pull Request`可以和[功能分支工作流](workflow-feature-branch.md)、[`Gitflow`工作流](workflow-gitflow.md)或[`Forking`工作流](workflow-forking.md)一起使用。
 但一个`Pull Request`需求要么分支不同要么仓库不同，所以不能用于[集中式工作流](workflow-centralized.md)。
 在不同的工作流中使用`Pull Request`会稍许不同，但基本的过程是这样的：
 
@@ -66,6 +66,47 @@
 
 ### 在`Gitflow`工作流中使用`Pull Request`
 
+`Gitflow`工作流和功能分支工作流类似，但围绕项目发布定义一个严格的分支模型。
+在`Gitflow`工作流中使用`Pull Request`让开发者在工作时可以有个方便的地方关于发布分支或是维护分支进行交流。
+
+![](images/gitflow-workflow-pull-request.png)
+
+`Gitflow`工作流中`Pull Request`的使用过程和上一节中完全一致：
+当一个功能、发布或是热修复分支需要`Review`时，开发者简单发起一个`Pull Request`，
+团队的其它成员会通过`Bitbucket`收到通知。
+
+新功能一般合并到`develop`分支，而发布和热修复则要同时合并到`develop`分支和`master`分支上。
+`Pull Request`可能用做所有合并的正式管理。
+
+### 在`Forking`工作流中使用`Pull Request`
+
+在`Forking`工作流中，开发者`push`完成的功能到他自己的仓库中，而不是共享仓库。
+然后，他发起一个`Pull Request`，让项目维护者知道他的功能已经可以`Review`了。
+
+在这个工作流，`Pull Request`的通知功能非常有用，
+因为项目维护者不可能知道其它开发者在他们自己的仓库添加了提交。
+
+![](images/pull-request-forking-workflow-1.png)
+
+由于各个开发有自己的分开仓库，`Pull Request`的源仓库和目标仓库不是同一个。
+源仓库是开发者的公开仓库，源分支是包含了修改的分支。
+如果开发者要合并修改到正式代码库中，那么目标仓库是正式仓库，目标分支是`master`分支。
+
+`Pull Request`也可以用于正式项目之外的其它开发之前的协作。
+比如，如果一个开发者和一个团队成员一起开发一个功能，他们可以发起一个`Pull Request`，
+用团队成员的`Bitbucket`仓库作为目标，而不是正式项目的仓库。
+然后使用相同的功能分支作为源和目标分支。
+
+![](images/pull-request-forking-workflow-2.png)
+
+2个开发者之间可以在`Pull Request`中讨论和开发功能。
+完成开发后，他们可以另一个`Pull Request`，请求合并功能到正式的`master`分支。
+在`Forking`工作流中，这样的灵活性让`Pull Request`成为一个强有力的协作工具。
+
+:beer: 示例
+---------------------
+
+
 
 -----------------