finish workflow-feature-branch draft

git-workflows-and-tutorials/workflow-feature-branch.md

@@ -67,6 +67,8 @@ git commit
 
 ### 小红要去吃个午饭
 
+![](images/git-workflow-feature-branch-3.png)
+
 早上小红为新功能添加一些提交。
 去吃午饭前，`push`功能分支到中央仓库是很好的做法，这是一个方便的备份，如果和其它开发协作，也让他们可以看到小红的提交。
 
@@ -78,3 +80,71 @@ git push -u origin marys-feature
 设置好跟踪的分支后，小红就可以使用`git push`命令省去指定推送分支的参数。
 
 ### 小红完成功能开发
+
+![](images/git-workflow-feature-branch-4.png)
+
+小红吃完午饭回来，完成整个功能的开发。[在合并到`master`之前](https://www.atlassian.com/git/tutorial/git-branches#!merge)，
+她发起一个`Pull Request`让团队的其它人知道功能已经完成。但首先，她要确认中央仓库中已经有她最近的提交：
+
+```bash
+git push
+```
+
+然后，在她的`Git` `GUI`客户端中发起`Pull Request`，请求合并`marys-feature`到`master`，团队成员会自动收到通知。
+`Pull Request`很酷的是可以在相关的提交旁边显示评注，所以可以很对某个变更集提问。
+
+### 小黑收到`Pull Request`
+
+![](images/git-workflow-feature-branch-5.png)
+
+小黑收到了`Pull Request`后会查看`marys-feature`的修改。决定在合并到正式项目前是否要做些修改，且通过`Pull Request`和小红来回地讨论。
+
+### 小红再做修改
+
+![](images/git-workflow-feature-branch-6.png)
+
+要再做修改，小红用和功能第一个迭代完全一样的过程。编辑、暂存、提交并`push`更新到中央仓库。小红这些活动都会显示在`Pull Request`上，小黑可以断续做评注。
+
+如果小黑有需要，也可以把`marys-feature`分支拉到本地，自己来修改，他加的提交也会一样显示在`Pull Request`上。
+
+### 小红发布她的功能
+
+![](images/git-workflow-feature-branch-7.png)
+
+一旦小黑可以的接受`Pull Request`，就可以合并功能到稳定项目代码中（可以由小黑或是小红来做这个操作）：
+
+```bash
+git checkout master
+git pull
+git pull origin marys-feature
+git push
+```
+
+无论谁来做合并，首先要检出`master`分支并确认是它是最新的。然后执行`git pull origin marys-feature`合并`marys-feature`分支到和远程一致的本地`master`分支。
+你可以使用简单`git merge marys-feature`命令，但前面的命令可以保证总是最新的新功能分支。
+最后更新的`master`分支要重新`push`回到`origin`。
+
+这个过程常常会生成一个合并提交。有些开发者喜欢有合并提交，因为它像一个新功能和原来代码基线的连通符。
+但如果你偏爱线性的提交历史，可以在执行合并时`rebase`新功能到`master`分支的顶部，这样生成一个快进（`fast-forward`）的合并。
+
+一些`GUI`客户端可以只要点一下『接受』按钮执行好上面的命令来自动化`Pull Request`接受过程。
+如果你的不能这样，至少在功能合并到`master`分支后能自动关闭`Pull Request`。
+
+与此同时，小明在做小红一样的事
+
+当小红和小黑在`marys-feature`上工作并讨论她的`Pull Request`的时候，小明在自己的功能分支上做完全一样的事。
+
+通过隔离功能到独立的分支上，每个人都可以自主的工作，当然必要的时候在开发者之间分享变更还是比较繁琐的。
+
+:beer: 下一站
+-----------------
+
+现在但愿你发现了功能分支可以很直接地在[集中式工作流](workflow-centralized.md)的仅有的`master`分支上完成多功能的开发。
+另外，功能分支还使用了`Pull Request`，使得可以在你的版本控制`GUI`客户端中讨论某个提交。
+
+功能分支工作流是开发项目异常灵活的方式。问题是，有时候太灵活了。对于大型团队，常常需要给不同分支分配一个更具体的角色。
+`Gitflow`工作流是管理功能开发、发布准备和维护的常用模式。
+
+-----------------
+
+[集中式工作流 »](workflow-centralized.md)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　[`Gitflow`工作流 »](workflow-gitflow.md)