merge fix from xirong

git-workflows-and-tutorials/workflow-centralized.md

@@ -72,7 +72,7 @@ git clone ssh://user@host/path/to/repo.git
 ![](images/git-workflow-svn-1.png)
 
 在小明的本地仓库中，他使用标准的`Git`过程开发功能：编辑、暂存（`Stage`）和提交。
-如果你不熟悉暂存区（`Staging Area`），这里说明一下：**暂存区**的用来准备一个提交，但可以不用把工作目录中所有的修改内容都包含进来。
+如果你不熟悉暂存区（`Staging Area`），这里说明一下：**暂存区**用来准备一个提交，但可以不用把工作目录中所有的修改内容都包含进来。
 这样你可以创建一个高度聚焦的提交，尽管你本地修改很多内容。
 
 ```bash
@@ -153,7 +153,7 @@ git pull --rebase origin master
 这意味着可能要解决在迁移某个提交时出现的合并冲突，而不是解决包含了所有提交的大型合并时所出现的冲突。
 这样的方式让你尽可能保持每个提交的聚焦和项目历史的整洁。反过来，简化了哪里引入`Bug`的分析，如果有必要，回滚修改也可以做到对项目影响最小。
 
-如果小红和小明的功能是相关的，不大可能在`rebase`过程中有冲突。如果有，`Git`在合并有冲突的提交处暂停`rebase`过程，输出下面的信息并带上相关的指令：
+如果小红和小明的功能是不相关的，不大可能在`rebase`过程中有冲突。如果有，`Git`在合并有冲突的提交处暂停`rebase`过程，输出下面的信息并带上相关的指令：
 
 ```
 CONFLICT (content): Merge conflict in <some-file>

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

@@ -24,7 +24,7 @@
 在`master`分支和功能分支之间，`Git`是没有技术上的区别，所以开发者可以用和集中式工作流中完全一样的方式编辑、暂存和提交修改到功能分支上。
 
 另外，功能分支也可以（且应该）`push`到中央仓库中。这样不修改正式代码就可以和其它开发者分享提交的功能。
-由于`master`仅有的一个『特殊』分支，在中央仓库上存多个功能分支不会有任何问题。当然，这样做也可以很方便地备份各自的本地提交。
+由于`master`是仅有的一个『特殊』分支，在中央仓库上存多个功能分支不会有任何问题。当然，这样做也可以很方便地备份各自的本地提交。
 
 ### `Pull Requests`
 
@@ -91,7 +91,7 @@ git push
 ```
 
 然后，在她的`Git` `GUI`客户端中发起`Pull Request`，请求合并`marys-feature`到`master`，团队成员会自动收到通知。
-`Pull Request`很酷的是可以在相关的提交旁边显示评注，所以你可以很对某个变更集提问。
+`Pull Request`很酷的是可以在相关的提交旁边显示评注，所以你可以对某个变更集提问。
 
 ### 小黑收到`Pull Request`