fix typo

Merge pull request oldratlee#24 from JeffreyChu/master
alexsheng88 · May 30, 2016 · e61059f · e61059f
1 parent 6356296
commit e61059f
Show file tree

Hide file tree

Showing 4 changed files with 8 additions and 8 deletions.
diff --git a/git-workflows-and-tutorials/pull-request.md b/git-workflows-and-tutorials/pull-request.md
@@ -125,7 +125,7 @@
 下面的示例演示了`Pull Request`如何在在`Forking`工作流中使用。
 也同样适用于小团队的开发协作和第三方开发者向开源项目的贡献。
 
-在示例中，小红是个开发，小明是项目维护者。他们各自有一个公开的`Bitbucket`仓库，而小明的仓库包含了正式工程。
+在示例中，小红是个开发者，小明是项目维护者。他们各自有一个公开的`Bitbucket`仓库，而小明的仓库包含了正式工程。
 
 ### 小红`fork`正式项目
 

diff --git a/git-workflows-and-tutorials/workflow-feature-branch.md b/git-workflows-and-tutorials/workflow-feature-branch.md
@@ -21,7 +21,7 @@
 这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。
 另外，也保证了`master`分支的代码一定不会是有问题的，极大有利于集成环境。
 
-功能开发隔离也让[`pull requests`工作流](pull-request.md)成功可能，
+功能开发隔离也让[`pull requests`工作流](pull-request.md)成为可能，
 `pull requests`工作流能为每个分支发起一个讨论，在分支合入正式项目之前，给其它开发者有表示赞同的机会。
 另外，如果你在功能开发中有问题卡住了，可以开一个`pull requests`来向同学们征求建议。
 这些做法的重点就是，`pull requests`让团队成员之间互相评论工作变成非常方便！
@@ -44,7 +44,7 @@
 一旦某个开发完成一个功能，不是立即合并到`master`，而是`push`到中央仓库的功能分支上并发起一个`Pull Request`请求去合并修改到`master`。
 在修改成为主干代码前，这让其它的开发者有机会先去`Review`变更。
 
-`Code Review`是`Pull Requests`的一个重要的收益，但`Pull Requests`目的是讨论代码一个通用方式。
+`Code Review`是`Pull Requests`的一个主要的收益，但`Pull Requests`实际上用作讨论代码的常用手段。
 你可以把`Pull Requests`作为专门给某个分支的讨论。这意味着可以在更早的开发过程中就可以进行`Code Review`。
 比如，一个开发者开发功能需要帮助时，要做的就是发起一个`Pull Request`，相关的人就会自动收到通知，在相关的提交旁边能看到需要帮助解决的问题。
 
@@ -130,7 +130,7 @@ git push
 
 ![](images/git-workflow-feature-branch-7.png)
 
-一旦小黑可以的接受`Pull Request`，就可以合并功能到稳定项目代码中（可以由小黑或是小红来做这个操作）：
+一旦小黑可以接受`Pull Request`，就可以合并功能到稳定项目代码中（可以由小黑或是小红来做这个操作）：
 
 ```bash
 git checkout master
@@ -139,7 +139,7 @@ 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`。
 

diff --git a/git-workflows-and-tutorials/workflow-forking.md b/git-workflows-and-tutorials/workflow-forking.md
@@ -41,7 +41,7 @@
 然后，给正式仓库发起一个`pull request`，让项目维护者知道有更新已经准备好可以集成了。
 对于贡献的代码，`pull request`也可以很方便地作为一个讨论的地方。
 
-为了集成功能到正式代码库，维护者`pull`贡献者的变更到自己的本地仓库中，检查变更以确保不会让项目出错，
+为了把功能集成到正式代码库，维护者`pull`贡献者的变更到自己的本地仓库中，检查变更以确保不会让项目出错，
 [合并变更到自己本地的`master`分支](https://www.atlassian.com/git/tutorial/git-branches#!merge)，
 然后[`push`](https://www.atlassian.com/git/tutorial/remote-repositories#!push)`master`分支到服务器的正式仓库中。
 到此，贡献的提交成为了项目的一部分，其它的开发者应该执行`pull`操作与正式仓库同步自己本地仓库。

diff --git a/git-workflows-and-tutorials/workflow-gitflow.md b/git-workflows-and-tutorials/workflow-gitflow.md
@@ -137,8 +137,8 @@ git commit
 # 拉取远程的develop分支，并且当前分支（本地分支some-feature）合并上远程分支develop
 git pull origin develop
 git checkout develop
-# 本地分支some-feature合并上some-feature
-#【注意】已经这个分支已经有远程的develop修改了，所以本地develop无需再做远程拉取的操作
+# 本地分支some-feature合并上develop
+#【注意】这个分支已经有远程的develop修改了，所以本地develop无需再做远程拉取的操作
 git merge some-feature
 git push
 # 删除本地分支