diff --git a/sources/使用分支.md b/sources/使用分支.md index d005d7d..67b24b6 100644 --- a/sources/使用分支.md +++ b/sources/使用分支.md @@ -60,7 +60,7 @@ Git 分支背后的实现远比 SVN 的模型要轻量。与其在目录之间 这使得 Git 的合并模型变成了动态的。SVN 中的合并是基于文件的，而Git 让你在更抽象的提交层面操作。事实上，你可以看到项目历史中的合并其实是将两个独立的提交历史连接起来。 -### 例子 +### 栗子 #### 创建分支 diff --git a/sources/保存你的更改.md b/sources/保存你的更改.md index a13a1ab..69b79c0 100644 --- a/sources/保存你的更改.md +++ b/sources/保存你的更改.md @@ -46,7 +46,7 @@ git add -p 缓存允许你在实际提交到项目历史之前，将相关的更改组合成一份高度专注的快照，而不是将你上次提交以后产生的所有更改一并提交。也就是说你可以更改各种不相关的文件，然后回过去将它们按逻辑切分，将相关的更改添加到缓存，一份一份提交。在任何修改控制系统中，很重要的一点是提交必须是原子性的，以便于追踪 bug，并用最小的代价回滚更改。 -### 例子 +### 栗子 当你开始新项目的时候，`git add` 和 `svn import` 类似。为了创建当前目录的初始提交，使用下面两个命令： @@ -106,9 +106,9 @@ SVN 和 Git 除了使用上存在巨大差异，它们底层的实现同样遵 Git 的快照模型对它版本控制模型的方方面面都有着深远的影响，从分支到合并工具，再到协作工作流，以至于影响了所有特性。 -### 例子 +### 栗子 -下面这个例子假设你编辑了 `hello.py` 文件的一些内容，并且准备好将它提交到项目历史。首先，你需要用 `git add` 缓存文件，然后提交缓存的快照。 +下面这个栗子假设你编辑了 `hello.py` 文件的一些内容，并且准备好将它提交到项目历史。首先，你需要用 `git add` 缓存文件，然后提交缓存的快照。 ``` git add hello.py diff --git a/sources/保持代码同步.md b/sources/保持代码同步.md index 7bccde0..2708f52 100644 --- a/sources/保持代码同步.md +++ b/sources/保持代码同步.md @@ -72,7 +72,7 @@ ssh://user@host/path/to/repo.git 你需要在托管的服务器上有一个有效的 SSH 账户，但不用麻烦了，Git 支持开箱即用的 SSH 认证连接。 -### 例子 +### 栗子 除了 origin 之外，添加你同事的仓库连接通常会带来一些便利。比如，如果你的同事 John 在 `dev.example.com/john.git` 上维护了一个公开的仓库，你可以这样添加连接： @@ -117,7 +117,7 @@ git branch -r 同样，你可以用寻常的 `git checkout` 和 `git log` 命令来查看这些分支。如果你接受远程分支包含的更改，你可以使用 `git merge` 将它并入本地分支。所以，不像 SVN，同步你的本地仓库和远程仓库事实上是一个分两步的操作：先 fetch，然后 merge。`git pull` 命令是这个过程的快捷方式。 -### 例子 +### 栗子 这个例子回顾了同步本地和远程仓库 `master` 分支的常见工作流： @@ -201,9 +201,9 @@ git config --global pull.rebase true # In git >= 1.7.9 在运行这个命令之后，所有的 `git pull` 命令将使用 `git rebase` 而不是 `git merge`。 -### 例子 +### 栗子 -下面的例子演示了如何和一个中央仓库的 `master branch` 同步： +下面的栗子演示了如何和一个中央仓库的 `master branch` 同步： ``` git checkout master @@ -264,9 +264,9 @@ Git 为了防止你覆盖中央仓库的历史，会拒绝你会导致非快速 此外，你只应该推送到那些用 `--bare` 标记初始化的仓库。因为推送会弄乱远程分支结构，很重要的一点是，永远不要推送到其他开发者的仓库。但因为裸仓库没有工作目录，不会发生打断别人的开发之类的事情。 -### 例子 +### 栗子 -下面的例子描述了将本地提交推送到中央仓库的一些标准做法。首先，确保你本地的 `master` 和中央仓库的副本是一致的，提前 fetch 中央仓库的副本并在上面 rebase。交互式 rebase 同样是共享之前清理提交的好机会。接下来，`git push` 命令将你本地 `master` 分支上的所有提交发送给中央仓库. +下面的栗子描述了将本地提交推送到中央仓库的一些标准做法。首先，确保你本地的 `master` 和中央仓库的副本是一致的，提前 fetch 中央仓库的副本并在上面 rebase。交互式 rebase 同样是共享之前清理提交的好机会。接下来，`git push` 命令将你本地 `master` 分支上的所有提交发送给中央仓库. ``` git checkout master diff --git a/sources/创建PullRequest.md b/sources/创建PullRequest.md index 6968763..e01cd52 100644 --- a/sources/创建PullRequest.md +++ b/sources/创建PullRequest.md @@ -4,7 +4,7 @@ > > 这是一篇在[原文（BY atlassian）](https://www.atlassian.com/git/tutorials/making-a-pull-request)基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名（[CC BY 2.5 AU](http://creativecommons.org/licenses/by/2.5/au/deed.zh)）协议共享。 > -> 原文以 Bitbucket 为例，考虑到[git-recipes](https://github.com/geeeeeeeeek/git-recipes/)主要面向 GitHub 用户，因此例子替换成了 GitHub。Pull Request 在 GitLab 等平台上也有，用法和本教程基本一致。 +> 原文以 Bitbucket 为例，考虑到[git-recipes](https://github.com/geeeeeeeeek/git-recipes/)主要面向 GitHub 用户，因此栗子替换成了 GitHub。Pull Request 在 GitLab 等平台上也有，用法和本教程基本一致。 Pull Request 是开发者使用 GitHub 进行协作的利器。这个功能为用户提供了友好的页面，让提议的更改在并入官方项目之前，可以得到充分的讨论。 @@ -78,11 +78,11 @@ Pull Request 还可以用来和官方项目之外的开发者进行协作。比 两个开发者可以在 Pull Request 中讨论和开发分支。当功能完成时，其中一位可以发起另一个 Pull Request，请求将功能合并到官方的 master 分支中去。这种灵活性使得 Pull Request 成为了 Fork 工作流中尤为强大的协作工具。 -## 例子 +## 栗子 -下面的例子演示了如何将 Pull Request 用在 Fork 工作流中。小团队中的开发和向一个开源项目贡献代码都可以这样做。 +下面的🌰演示了如何将 Pull Request 用在 Fork 工作流中。小团队中的开发和向一个开源项目贡献代码都可以这样做。 -在这个例子中，Mary 是一位开发者，John 是项目的维护者。他们都有自己公开的 GitHub 仓库，John 的仓库之一便是下面的官方项目。 +在这个栗子中，Mary 是一位开发者，John 是项目的维护者。他们都有自己公开的 GitHub 仓库，John 的仓库之一便是下面的官方项目。 ### Mary fork了官方项目 @@ -156,7 +156,7 @@ John 可以在他自己的 GitHub 仓库下的 *Pull Request* 选项卡中看到 如果他认为 feature 分支已经可以合并了，他只需点击 *Merge Pull Request* 按钮来通过这个 Pull Request，将 Mary 的 feature分支并入他的 `master` 分支。 -但是，在这里例子中，假设 John 发现了 Mary 代码中的一个小 bug，需要她在合并前修复。他可以评论整个 Pull Request，也可以评论 feature 分支中某个特定的提交。 +但是，在这里栗子中，假设 John 发现了 Mary 代码中的一个小 bug，需要她在合并前修复。他可以评论整个 Pull Request，也可以评论 feature 分支中某个特定的提交。 ![qq20160127-4](https://cloud.githubusercontent.com/assets/7262715/12615732/67c8c872-c542-11e5-9734-71751b83f63c.png) diff --git a/sources/创建代码仓库.md b/sources/创建代码仓库.md index ee9de0d..f2b182c 100644 --- a/sources/创建代码仓库.md +++ b/sources/创建代码仓库.md @@ -46,7 +46,7 @@ git init --bare ![](https://www.atlassian.com/git/images/tutorials/getting-started/setting-up-a-repository/01.svg) -### 例子 +### 栗子 因为 `git clone` 创建项目的本地拷贝更为方便，`git init` 最常见的使用情景就是用于创建中央仓库： @@ -96,7 +96,7 @@ git clone 当然，你也完全可以给予某个特定的仓库一些特殊的含义。比如，指定某个 Git 仓库为中央仓库，你就可以用 Git 进行中央化的工作流。重点是，这是通过约定实现的，而不是写死在版本控制系统本身。 -### 例子 +### 栗子 下面这个例子演示用 SSH 用户名 john 连接到 example.com，获取远程服务器上中央仓库的本地副本： @@ -196,7 +196,7 @@ editor = vim 你可以用 `git config` 手动编辑这些值。 -### 例子 +### 栗子 你在安装 Git 之后想要做的第一件事是告诉它你的名字和邮箱，个性化一些默认设置。一般初始的设置过程看上去是这样的： diff --git a/sources/回滚错误的修改.md b/sources/回滚错误的修改.md index c472297..8f89499 100644 --- a/sources/回滚错误的修改.md +++ b/sources/回滚错误的修改.md @@ -38,9 +38,9 @@ git revert 其次，`git revert` 可以针对历史中任何一个提交，而 `git reset` 只能从当前提交向前回溯。比如，你想用 `git reset` 重设一个旧的提交，你不得不移除那个提交后的所有提交，再移除那个提交，然后重新提交后面的所有提交。不用说，这并不是一个优雅的回滚方案。 -### 例子 +### 栗子 -下面的这个例子是 `git revert` 一个简单的演示。它提交了一个快照，然后立即撤销这个操作。 +下面的这个栗子是 `git revert` 一个简单的演示。它提交了一个快照，然后立即撤销这个操作。 ``` # 编辑一些跟踪的文件 @@ -116,7 +116,7 @@ git reset --hard 重点是，确保你只对本地的修改使用 `git reset`，而不是公共更改。如果你需要修复一个公共提交，`git revert` 命令正是被设计来做这个的。 -### 例子 +### 栗子 #### 取消文件缓存 @@ -146,7 +146,7 @@ git commit -m "Edit main.py" #### 移除本地修改 -下面的这个例子显示了一个更高端的用法。它展示了你作了大死之后应该如何扔掉那几个更新。 +下面的这个栗子显示了一个更高端的用法。它展示了你作了大死之后应该如何扔掉那几个更新。 ``` # 创建一个叫`foo.py`的新文件，增加代码 @@ -212,9 +212,9 @@ git clean -xf 请牢记，和 `git reset` 一样， `git clean` 是仅有的几个可以永久删除提交的命令之一，所以要小心使用。事实上，它太容易丢掉重要的修改了，以至于 Git 厂商 *强制* 你用 `-f` 标志来进行最基本的操作。这可以避免你用一个 `git clean` 就不小心删除了所有东西。 -### 例子 +### 栗子 -下面的例子清除了工作目录中的所有更改，包括新建还没加入缓存的文件。它假设你已经提交了一些快照，准备开始一些新的实验。 +下面的栗子清除了工作目录中的所有更改，包括新建还没加入缓存的文件。它假设你已经提交了一些快照，准备开始一些新的实验。 ``` # 编辑了一些文件 @@ -230,7 +230,7 @@ git clean -df 在执行了 reset/clean 的流程之后，工作目录和缓存区和最近一次提交看上去一模一样，而 `git status`会认为这是一个干净的工作目录。你可以重新来过了。 -注意，不像 `git reset` 的第二个例子，新的文件没有被加入到仓库中。因此，它们不会受到 `git reset --hard` 的影响，需要 `git clean` 来删除它们。 +注意，不像 `git reset` 的第二个栗子，新的文件没有被加入到仓库中。因此，它们不会受到 `git reset --hard` 的影响，需要 `git clean` 来删除它们。 > 这篇文章是[**「git-recipes」**](https://github.com/geeeeeeeeek/git-recipes/)的一部分，点击[**目录**](https://github.com/geeeeeeeeek/git-recipes/wiki/)查看所有章节。 > diff --git a/sources/常见工作流比较.md b/sources/常见工作流比较.md index f01ebce..546e093 100644 --- a/sources/常见工作流比较.md +++ b/sources/常见工作流比较.md @@ -45,7 +45,7 @@ 如果本地修改和上游提交冲突时，Git 会暂停 rebase 流程，给你机会手动解决这些冲突。Git 很赞的一点是，它将 [`git status`](https://github.com/geeeeeeeeek/git-recipes/wiki/2.4-%E6%A3%80%E6%9F%A5%E4%BB%93%E5%BA%93%E7%8A%B6%E6%80%81#git-status) 和 [`git add`](https://github.com/geeeeeeeeek/git-recipes/wiki/2.3-%E4%BF%9D%E5%AD%98%E4%BD%A0%E7%9A%84%E6%9B%B4%E6%94%B9#git-add) 命令同时用来生成提交和解决合并冲突。这使得开发者能够轻而易举地管理他们的合并。另外，如果他们改错了什么，Git 让他们轻易地退出 rebase 过程，然后重试（或者找人帮忙）。 -## 例子 +## 栗子 让我们一步步观察一个普通的小团队是如何使用这种工作流协作的。我们有两位开发者，John 和 Mary，分别在开发两个功能，他们通过中心化的仓库共享代码。 @@ -226,9 +226,9 @@ Git 在技术上无法区别 `master` 和功能分支，所以开发者可以在 一旦 Pull Request 被接受了，发布功能的行为和中心化的工作流是一样的。首先，确定你本地的 `master` 和上游的 `master` 已经同步。然后，将 feature分支并入 `master`，将更新的 `master` 推送回中央仓库。 -## 例子 +## 栗子 -下面这例子演示了代码审查使用到的 Pull Request，但记住 Pull Request 有多种用途。 +下面这🌰演示了代码审查使用到的 Pull Request，但记住 Pull Request 有多种用途。 ### Mary 开始了一个新功能 @@ -365,9 +365,9 @@ GitFlow 工作流仍然使用中央仓库作为开发者沟通的中心。和[ 有一个专门的 bug 修复开发线使得你的团队能够处理 issues，而不打断其他工作流或是要等到下一个发布周期。你可以将维护分支看作在 `master` 分支上工作的临时发布分支。 -## 例子 +## 栗子 -下面的例子演示了这种工作流如何用来管理发布周期。假设你已经创建了中央仓库。 +下面的栗子演示了这种工作流如何用来管理发布周期。假设你已经创建了中央仓库。 ### 创建一个开发分支 @@ -393,7 +393,7 @@ git checkout -b develop origin/develop ![New Feature Branches](https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/gitflow-workflow/07.svg) -我们的例子从 John 和 Mary 在不同分支上工作开始。他们都要为自己的功能创建单独的分支。[他们的功能分支都应该基于`develop`](https://github.com/geeeeeeeeek/git-recipes/wiki/3.4-%E4%BD%BF%E7%94%A8%E5%88%86%E6%94%AF#git-checkout)，而不是 `master`： +我们的栗子从 John 和 Mary 在不同分支上工作开始。他们都要为自己的功能创建单独的分支。[他们的功能分支都应该基于`develop`](https://github.com/geeeeeeeeek/git-recipes/wiki/3.4-%E4%BD%BF%E7%94%A8%E5%88%86%E6%94%AF#git-checkout)，而不是 `master`： ``` git checkout -b some-feature develop @@ -519,7 +519,7 @@ Fork 工作流的主要优点在于贡献可以轻易地整合进项目，而不 所有这些个人的公开仓库只是一个在开发者之间共享分支的约定。每个人仍然可以使用分支来隔离功能，就像在[功能分支工作流](](https://github.com/geeeeeeeeek/git-recipes/wiki/3.5-%E5%B8%B8%E8%A7%81%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%AF%94%E8%BE%83#feature%E5%88%86%E6%94%AF%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%B5%81))和 [GitFlow 工作流中](https://github.com/geeeeeeeeek/git-recipes/wiki/3.5-%E5%B8%B8%E8%A7%81%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%AF%94%E8%BE%83#gitflow%E5%B7%A5%E4%BD%9C%E6%B5%81)一样。唯一的区别在于这些分支是如何开始的。在 Fork 工作流中，它们从另一个开发者的本地仓库拉取而来，而在功能分支和 GitFlow 分支它们被推送到官方仓库。 -## 例子 +## 栗子 ### 项目维护者初始化了中央仓库 @@ -550,7 +550,7 @@ GitHub 同时提供了一个图形化界面来替代上面的操作。这和教 接下来开发者需要克隆他们自己的公开仓库。他们可以用熟悉的 `git clone` 命令来完成这一步。 -我们的例子假设使用他们使用 GitHub 来托管仓库。记住，在这种情况下，每个开发者应该有他们自己的 GitHub 账号，应该用下面的命令克隆服务端仓库： +我们的栗子假设使用他们使用 GitHub 来托管仓库。记住，在这种情况下，每个开发者应该有他们自己的 GitHub 账号，应该用下面的命令克隆服务端仓库： ``` git clone https://user@github.com/user/repo.git diff --git a/sources/查看仓库状态.md b/sources/查看仓库状态.md index d5d12ed..fe8f8bf 100644 --- a/sources/查看仓库状态.md +++ b/sources/查看仓库状态.md @@ -49,7 +49,7 @@ git status *.pyc ``` -### 例子 +### 栗子 在提交更改前检查仓库状态是一个良好的实践，这样你就不会不小心提交什么奇怪的东西。这个例子显示了缓存和提交快照前后的仓库状态： @@ -154,9 +154,9 @@ Author: John Smith 所有这些标识方法的背后都是为了让你对特定提交进行操作。`git log` 命令一般是这些交互的起点，因为它让你找到你想要的提交。 -### 例子 +### 栗子 -*用法* 一节提供了 `git log` 很多的例子，但请记住，你可以将很多选项用在同一个命令中： +*用法* 一节提供了 `git log` 很多的栗子，但请记住，你可以将很多选项用在同一个命令中： ``` git log --author="John Smith" -p hello.py @@ -164,7 +164,7 @@ git log --author="John Smith" -p hello.py 这个命令会显示 `John Smith` 作者对 `hello.py` 文件所做的所有更改的差异比较（diff）。 -..句法是比较分支很有用的工具。下面的例子显示了在 `some-feature` 分支而不在 `master` 分支的所有提交的概览。 +..句法是比较分支很有用的工具。下面的栗子显示了在 `some-feature` 分支而不在 `master` 分支的所有提交的概览。 ``` git log --oneline master..some-feature diff --git a/sources/检出以前的提交.md b/sources/检出以前的提交.md index 85288e9..ac80e35 100644 --- a/sources/检出以前的提交.md +++ b/sources/检出以前的提交.md @@ -42,11 +42,11 @@ git checkout ![Git Training: Checking out a previous version of a file](https://www.atlassian.com/git/images/tutorials/getting-started/viewing-old-commits/02.svg) -### 例子 +### 栗子 #### 查看之前的版本 -这个例子假定你开始了一个疯狂的实验，但你不确定你是否想要保留它。为了帮助你决定，你想看一看你开始实验之前的项目状态。首先，你需要找到你想要看的那个版本的 ID。 +这个栗子假定你开始了一个疯狂的实验，但你不确定你是否想要保留它。为了帮助你决定，你想看一看你开始实验之前的项目状态。首先，你需要找到你想要看的那个版本的 ID。 ``` git log --oneline