revise git-workflows-and-tutorials, adjust wording

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

@@ -3,7 +3,7 @@
 
 `Forking`工作流和前面讨论的几种工作流有根本的不同。
 这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。
-这意味着各个代码贡献者有2个`Git`仓库而不是1个：一个本地私有的，另一个服务端公有的。
+这意味着各个代码贡献者有2个`Git`仓库而不是1个：一个本地私有的，另一个服务端公开的。
 
 ![](images/git-workflows-forking.png)
 
@@ -17,14 +17,14 @@
 :beer: 工作方式
 ---------------------
 
-和其它的`Git`工作流一样，`Forking`工作流要先有一个公有的正式仓库存储在服务器上。
+和其它的`Git`工作流一样，`Forking`工作流要先有一个公开的正式仓库存储在服务器上。
 但一个新的开发者想要在项目上工作时，不是直接从正式仓库克隆，而是`fork`正式项目在服务器上创建一个拷贝。
 
 这个仓库拷贝作为他个人公开仓库 ——
 其它开发者不允许`push`到这个仓库，但可以`pull`到修改（后面我们很快就会看这点很重要）。
 在创建了自己服务端拷贝之后，和之前的工作流一样，开发者执行[`git clone`命令](https://www.atlassian.com/git/tutorial/git-basics#!clone)克隆仓库到本地机器上，作为私有的开发环境。
 
-要提交本地修改时，`push`提交到自己公有仓库中 —— 而不是正式仓库中。
+要提交本地修改时，`push`提交到自己公开仓库中 —— 而不是正式仓库中。
 然后，给正式仓库发起一个`pull request`，让项目维护者知道有更新已经准备好可以集成了。
 对于贡献的代码，`pull request`也可以很方便地作为一个讨论的地方。
 
@@ -53,9 +53,9 @@
 ![](images/git-workflows-forking-1.png)
 
 和任何使用`Git`项目一样，第一步是创建在服务器上一个正式仓库，让所有团队成员都可以访问到。
-通常这个仓库也会作为项目维护者的公有仓库。
+通常这个仓库也会作为项目维护者的公开仓库。
 
-[公有仓库应该是裸仓库](https://www.atlassian.com/git/tutorial/git-basics#!init)，不管是不是正式代码库。
+[公开仓库应该是裸仓库](https://www.atlassian.com/git/tutorial/git-basics#!init)，不管是不是正式代码库。
 所以项目维护者会运行像下面的命令来搭建正式仓库：
 
 ```bash
@@ -82,7 +82,7 @@ git init --bare /path/to/repo.git
 
 ![](images/git-workflows-forking-3.png)
 
-下一步，各个开发者要克隆自己的公有仓库，用熟悉的`git clone`命令。
+下一步，各个开发者要克隆自己的公开仓库，用熟悉的`git clone`命令。
 
 在这个示例中，假定用`Bitbucket`托管了仓库。记住，如果这样的话各个开发者需要有各自的`Bitbucket`账号，
 使用下面命令克隆服务端自己的仓库：
@@ -172,7 +172,7 @@ git merge FETCH_HEAD
 git push origin master
 ```
 
-注意，维护者的`origin`是指向他自己公有仓库的，即是项目的正式代码库。到此，开发者的贡献完全集成到了项目中。
+注意，维护者的`origin`是指向他自己公开仓库的，即是项目的正式代码库。到此，开发者的贡献完全集成到了项目中。
 
 ### 开发者和正式仓库做同步