diff --git a/git-workflows-and-tutorials/README.md b/git-workflows-and-tutorials/README.md
index 2009e36..c438447 100644
--- a/git-workflows-and-tutorials/README.md
+++ b/git-workflows-and-tutorials/README.md
@@ -20,7 +20,7 @@
 
 ![Git Workflows: SVN-style](images/git-workflow-svn.png)
 
-### 功能分支（Feature Branch）工作流
+### 功能分支工作流
 
 功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个单独的分支来开发。这样可以在把新功能合并到正式主干前，用`Pull Requests`的方式讨论变更。
 
@@ -32,18 +32,24 @@
 
 `Gitflow`工作流通过为功能开发、发布准备和维护提供独立的分支，来简化发布迭代过程。严格的分支模型为大型项目提供了一些非常有必要的结构。
 
+[了解更多 »](workflow-gitflow.md)
+
 ![Git Workflows: Gitflow Cycle](images/git-workflows-gitflow.png)
 
 ### `Forking`工作流
 
 `Forking`工作流是分布式工作流，充分利用了`Git`在分支和克隆上的优势。可以安全可靠地管理大团队的开发者（`developer`），并能接受不信任贡献者（`contributor`）的提交。
 
+[了解更多 »](workflow-forking.md)
+
 ![Git Workflows: Forking](images/git-workflow-forking.png)
 
 ### `Pull Requests`
 
 `Pull requests`是`Bitbucket`让开发者更方便地进行协作的功能，提供了友好的Web界面可以在合并得提交的修改到官方项目之前对修改进行讨论。
 
+[了解更多 »](pull-request.md)
+
 ![Workflows: Pull Requests](images/pull-request.png)
 
 
diff --git a/git-workflows-and-tutorials/images/git-workflow-feature-branch-1.png b/git-workflows-and-tutorials/images/git-workflow-feature-branch-1.png
new file mode 100644
index 0000000..e0a931f
Binary files /dev/null and b/git-workflows-and-tutorials/images/git-workflow-feature-branch-1.png differ
diff --git a/git-workflows-and-tutorials/pull-request.md b/git-workflows-and-tutorials/pull-request.md
new file mode 100644
index 0000000..e69de29
diff --git a/git-workflows-and-tutorials/workflow-centralized.md b/git-workflows-and-tutorials/workflow-centralized.md
index fe81b68..9916602 100644
--- a/git-workflows-and-tutorials/workflow-centralized.md
+++ b/git-workflows-and-tutorials/workflow-centralized.md
@@ -195,11 +195,11 @@ git push origin master
 :beer: 下一站
 -----------------
 
-如你所见，仅使用几个`Git`命令就我们就可以模拟传统`Subversion`开发环境。对于要从`SVN`迁移的团队来说这太好了，但这没有发挥出`Git`分布式本质。
+如你所见，仅使用几个`Git`命令就我们就可以模拟传统`Subversion`开发环境。对于要从`SVN`迁移的团队来说这太好了，但这没有发挥出`Git`分布式本质的优势。
 
 如果你的团队适应了集中式工作流，并想更流畅的协作效果，绝对值得探索一下[功能分支工作流](workflow-feature-branch.md)。
 通过为一个功能分配一个隔离分支，使得一个新增功能集成到正式项目前对新功能进行深入讨论成为可能。
 
 -----------------
 
-[« Overview](README.md)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　[功能分支工作流 »](workflow-feature-branch.md)
+[« 概述](README.md)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　[功能分支工作流 »](workflow-feature-branch.md)
diff --git a/git-workflows-and-tutorials/workflow-feature-branch.md b/git-workflows-and-tutorials/workflow-feature-branch.md
index e69de29..c49e102 100644
--- a/git-workflows-and-tutorials/workflow-feature-branch.md
+++ b/git-workflows-and-tutorials/workflow-feature-branch.md
@@ -0,0 +1,24 @@
+功能分支工作流
+======================
+
+![](images/git-workflow-feature-branch-1.png)
+
+一旦你玩转了[集中式工作流](workflow-centralized.md)，在开发过程中加上功能分支是用来鼓励开发者之间协作和简化交流一个很简单的做法。
+
+功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在`master`分支上。
+这个隔离让可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。
+另外，也保证了`master`分支的代码一定不会是有问题的，极大有利于集成环境。
+
+功能开发隔离也让[`pull requests`](pull-request.md)工作流成功可能，
+[`pull requests`](pull-request.md)工作流能为每个分支发起一个讨论，给另外开发者在分支合入正式项目之前表示赞同机会。
+另外，如果你在功能开发中有问题卡住了，可以开一个`pull requests`来向同学们征求建议。
+这些做法的重点就是，`pull requests`让团队成员之间评论各自工作变成灰常方便！
+
+:beer: 工作方式
+---------------------
+
+功能分支工作流仍然用中央仓库，并且`master`分支还是代码正式的项目历史。
+但不是直接提交本地历史到各自的本地`master`分支，开发者每次在开始新功能前先创建一个新分支。
+功能分支应该有个有描述性的名字，比如`animated-menu-items`或`issue-#1061`，这样可以让分支有个清楚且高聚焦的目标。
+
+在`master`分支和功能分支，`Git`是没有技术的区别的。
diff --git a/git-workflows-and-tutorials/workflow-forking.md b/git-workflows-and-tutorials/workflow-forking.md
new file mode 100644
index 0000000..e69de29
diff --git a/git-workflows-and-tutorials/workflow-gitflow.md b/git-workflows-and-tutorials/workflow-gitflow.md
new file mode 100644
index 0000000..e69de29