From 0e3240c0f5a54d4947b3ea55d0fef2a2e993406a Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Wed, 10 Sep 2014 15:37:18 +0800 Subject: [PATCH] revise git-workflows-and-tutorials, adjust wording --- git-workflows-and-tutorials/pull-request.md | 4 ++-- git-workflows-and-tutorials/workflow-forking.md | 14 +++++++------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/git-workflows-and-tutorials/pull-request.md b/git-workflows-and-tutorials/pull-request.md index fea87e1..3b4f115 100644 --- a/git-workflows-and-tutorials/pull-request.md +++ b/git-workflows-and-tutorials/pull-request.md @@ -54,7 +54,7 @@ ![](images/pull-request-feature-branch.png) -功能分支工作流只有一个公有的仓库，所以`Pull Request`的目的仓库和源仓库总是同一个。 +功能分支工作流只有一个公开的仓库，所以`Pull Request`的目的仓库和源仓库总是同一个。 通常开发者会指定他的功能分支作为源分支，`master`分支作为目的分支。 收到`Pull Request`后，项目维护者要决定如何做。如果功能没问题，就简单地合并到`master`分支，关闭`Pull Request`。 @@ -110,7 +110,7 @@ 下面的示例演示了`Pull Request`如何在在`Forking`工作流中使用。 也同样适用于小团队的开发协作和第三方开发者向开源项目的贡献。 -在示例中，小红是个开发，小明是项目维护者。他们各自有一个公有的`Bitbucket`仓库，而小明的仓库包含了正式工程。 +在示例中，小红是个开发，小明是项目维护者。他们各自有一个公开的`Bitbucket`仓库，而小明的仓库包含了正式工程。 ### 小红`fork`正式项目 diff --git a/git-workflows-and-tutorials/workflow-forking.md b/git-workflows-and-tutorials/workflow-forking.md index 880aecd..9b2fb8f 100644 --- a/git-workflows-and-tutorials/workflow-forking.md +++ b/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`是指向他自己公开仓库的，即是项目的正式代码库。到此，开发者的贡献完全集成到了项目中。 ### 开发者和正式仓库做同步