diff --git a/git-workflows-and-tutorials/README.md b/git-workflows-and-tutorials/README.md
index 263aad8..52b7c39 100644
--- a/git-workflows-and-tutorials/README.md
+++ b/git-workflows-and-tutorials/README.md
@@ -15,14 +15,12 @@
 
 `Gitflow`工作流是经典模型，处于核心位置，体现了工作流的经验和精髓。随着项目过程复杂化，你会感受到这个工作流中的深思熟虑和威力！
 
-`Forking`工作流是分布式协作的（`GitHub`风格）可以先看看`GitHub`的Help：[Fork A Repo](https://help.github.com/articles/fork-a-repo/)和[Using pull requests](https://help.github.com/articles/using-pull-requests/) 。照着操作，给一个`GitHub`项目贡献你的提交，有操作经验再看指南容易意会。指南中给了[自己实现`Fork`的方法](https://github.com/oldratlee/translations/blob/master/git-workflows-and-tutorials/workflow-forking.md#%E5%BC%80%E5%8F%91%E8%80%85fork%E6%AD%A3%E5%BC%8F%E4%BB%93%E5%BA%93)：`Fork`就是服务端的克隆。在指南的操练中使用代码托管服务（如`GitHub`、`Bitbucket`），可以点一下按钮就让开发者完成仓库的`fork`操作。
+`Forking`工作流是分布式协作的（`GitHub`风格）可以先看看`GitHub`的Help：[Fork A Repo](https://help.github.com/articles/fork-a-repo/)和[Using pull requests](https://help.github.com/articles/using-pull-requests/) 。照着操作，给一个`GitHub`项目贡献你的提交，有操作经验再看指南容易意会。指南中给了[自己实现`Fork`的方法](https://github.com/oldratlee/translations/blob/master/git-workflows-and-tutorials/workflow-forking.md#%E5%BC%80%E5%8F%91%E8%80%85fork%E6%AD%A3%E5%BC%8F%E4%BB%93%E5%BA%93)：`Fork`就是服务端的克隆。在指南的操练中使用的是代码托管服务（如`GitHub`、[`Bitbucket`](https://bitbucket.org)），可以点一下按钮就让开发者完成仓库的`fork`操作。
+
+文中`Pull Request`的介绍用的是[`Bitbucket`](https://bitbucket.org)代码托管服务，由于和`GitHub`基本一样，如果你用的是`GitHub`（我自己也主要使用`GitHub`托管代码），不影响理解和操作。
 
 **_PS_**：
 
-文中`Pull Request`的介绍用的是`Bitbucket`代码托管服务，由于和`GitHub`基本一样，如果你用的是`GitHub`（我自己也主要使用`GitHub`托管代码），不影响理解和操作。
-
-**_PPS_**：
-
 更多`Git`学习资料参见
 
 - [`Git`的资料整理](https://github.com/xirong/my-git) by [@xirong](https://github.com/xirong)
diff --git a/git-workflows-and-tutorials/workflow-centralized.md b/git-workflows-and-tutorials/workflow-centralized.md
index d55413e..c8482b8 100644
--- a/git-workflows-and-tutorials/workflow-centralized.md
+++ b/git-workflows-and-tutorials/workflow-centralized.md
@@ -86,7 +86,7 @@ git clone ssh://user@host/path/to/repo.git
 ![](images/git-workflow-svn-1.png)
 
 在小明的本地仓库中，他使用标准的`Git`过程开发功能：编辑、暂存（`Stage`）和提交。
-如果你不熟悉暂存区（`Staging Area`），这里说明一下：**暂存区**用来准备一个提交，但可以不用把工作目录中所有的修改内容都包含进来。
+如果你不熟悉暂存区（`Staging Area`），这里说明一下：**暂存区** 用来准备一个提交，但可以不用把工作目录中所有的修改内容都包含进来。
 这样你可以创建一个高度聚焦的提交，尽管你本地修改很多内容。
 
 ```bash
@@ -113,7 +113,14 @@ git commit # 提交文件
 一旦小明完成了他的功能开发，会发布他的本地提交到中央仓库中，这样其它团队成员可以看到他的修改。他可以用下面的[`git push`命令](https://www.atlassian.com/git/tutorial/remote-repositories#!push)：
 
 ```bash
-git push origin master
+git push
+
+# 【译注】：
+# 原文用的命令是 git push origin master
+#
+# 主流的git版本，可以省略后面2个参数：远程仓库别名、推送分支，
+# 因为这个参数缺省分别就是 origin 、 当前分支（本文目前的示例就是master）。
+# 这样的用法更简单自然，我平时就是这么用的。
 ```
 
 注意，`origin`是在小明克隆仓库时`Git`创建的远程中央仓库别名。`master`参数告诉`Git`推送的分支。
@@ -126,12 +133,16 @@ git push origin master
 一起来看看在小明发布修改后，小红`push`修改会怎么样？她使用完全一样的`push`命令：
 
 ```bash
-git push origin master
+git push
+
+# 【译注】：
+# 原文用的命令是 git push origin master
+# 原因同上
 ```
 
 但她的本地历史已经和中央仓库有分岐了，`Git`拒绝操作并给出下面很长的出错消息：
 
-```
+```py
 error: failed to push some refs to '/path/to/repo.git'
 hint: Updates were rejected because the tip of your current branch is behind
 hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
@@ -149,7 +160,11 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 这条命令类似`svn update`——拉取所有上游提交命令到小红的本地仓库，并尝试和她的本地修改合并：
 
 ```bash
-git pull --rebase origin master
+git pull --rebase
+
+# 【译注】：
+# 原文用的命令是 git push --rebase origin master
+# 原因同上
 ```
 
 `--rebase`选项告诉`Git`把小红的提交移到同步了中央仓库修改后的`master`分支的顶部，如下图所示：
@@ -208,7 +223,11 @@ git rebase --abort
 小红完成和中央仓库的同步后，就能成功发布她的修改了：
 
 ```bash
-git push origin master
+git push
+
+# 【译注】：
+# 原文用的命令是 git push origin master
+# 原因同上
 ```
 
 :beer: 下一站
diff --git a/git-workflows-and-tutorials/workflow-feature-branch.md b/git-workflows-and-tutorials/workflow-feature-branch.md
index dadc997..78c6726 100644
--- a/git-workflows-and-tutorials/workflow-feature-branch.md
+++ b/git-workflows-and-tutorials/workflow-feature-branch.md
@@ -65,7 +65,14 @@
 在开始开发功能前，小红需要一个独立的分支。使用下面的命令[新建一个分支](https://www.atlassian.com/git/tutorial/git-branches#!checkout)：
 
 ```bash
-git checkout -b marys-feature master
+git checkout -b marys-feature
+
+# 【译注】：
+# 原文用的命令是 git checkout -b marys-feature master
+#
+# 主流的git版本，可以省略后一个参数：基于哪个分支新建分支，
+# 因为这个参数缺省分别就是 当前分支（本文目前的示例就是master）。
+# 这样的用法更简单自然，我平时就是这么用的。
 ```
 
 这个命令检出一个基于`master`名为`marys-feature`的分支，`Git`的`-b`选项表示如果分支还不存在则新建分支。
@@ -132,13 +139,25 @@ git pull origin marys-feature
 git push
 ```
 
-无论谁来做合并，首先要检出`master`分支并确认是它是最新的。然后执行`git pull origin marys-feature`合并`marys-feature`分支到和已经和远程一致的本地`master`分支。
+无论谁来做合并，首先要检出`master`分支并确认它是最新的。然后执行`git pull origin marys-feature`合并`marys-feature`分支到和已经和远程一致的本地`master`分支。
 你可以使用简单`git merge marys-feature`命令，但前面的命令可以保证总是最新的新功能分支。
 最后更新的`master`分支要重新`push`回到`origin`。
 
 这个过程常常会生成一个合并提交。有些开发者喜欢有合并提交，因为它像一个新功能和原来代码基线的连通符。
 但如果你偏爱线性的提交历史，可以在执行合并时`rebase`新功能到`master`分支的顶部，这样生成一个快进（`fast-forward`）的合并。
 
+【译注】生成一个快进的合并的命令行：（感觉步骤有些多:sweat:，欢迎给出更简捷的做法:two_hearts:）
+
+```bash
+git checkout marys-feature
+git pull # 确认是最新的
+git pull --rebase origin master # rebase新功能到master分支的顶部
+
+git checkout master
+git merge marys-feature # 合并marys-feature分支的修改，因为这个分支之前对齐（rebase）了master，一定是快进合并
+git push
+```
+
 一些`GUI`客户端可以只要点一下『接受』按钮执行好上面的命令来自动化`Pull Request`接受过程。
 如果你的不能这样，至少在功能合并到`master`分支后能自动关闭`Pull Request`。
 
diff --git a/git-workflows-and-tutorials/workflow-gitflow.md b/git-workflows-and-tutorials/workflow-gitflow.md
index beb4e5a..fd37d4f 100644
--- a/git-workflows-and-tutorials/workflow-gitflow.md
+++ b/git-workflows-and-tutorials/workflow-gitflow.md
@@ -101,6 +101,10 @@ git push -u origin develop
 ```bash
 git clone ssh://user@host/path/to/repo.git
 git checkout -b develop origin/develop
+
+#【译注】当没有本地分支 develop 时，
+# 最后一条命令，我使用更简单的 git checkout develop
+# 会自动 把 远程分支origin/develop 检出成 本地分支 develop
 ```
 
 现在每个开发都有了这些历史分支的本地拷贝。