Merge pull request #244 from networm/unify

Unify some define

Author: networm

book/02-git-basics/sections/getting-a-repository.asc

@@ -48,7 +48,7 @@ $ git commit -m 'initial project version'
 $ git clone https://github.com/libgit2/libgit2
 ----
 
-这会在当前目录下创建一个名为 ``libgit2`` 的目录，并在这个目录下初始化一个 `.git` 文件夹，从远程仓库拉取下所有数据放入 `.git` 文件夹，然后从中读取最新版本的文件的拷贝。
+这会在当前目录下创建一个名为 ``libgit2'' 的目录，并在这个目录下初始化一个 `.git` 文件夹，从远程仓库拉取下所有数据放入 `.git` 文件夹，然后从中读取最新版本的文件的拷贝。
 如果你进入到这个新建的 `libgit2` 文件夹，你会发现所有的项目文件已经在里面了，准备就绪等待后续的开发和使用。
 如果你想在克隆远程仓库的时候，自定义本地仓库的名字，你可以使用如下命令：
 

book/02-git-basics/sections/recording-changes.asc

@@ -30,10 +30,10 @@ nothing to commit, working directory clean
 这说明你现在的工作目录相当干净。换句话说，所有已跟踪文件在上次提交后都未被更改过。
 此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。
 最后，该命令还显示了当前所在分支，并告诉你这个分支同远程服务器上对应的分支没有偏离。
-现在，分支名是 ``master``,这是默认的分支名。
+现在，分支名是 ``master'',这是默认的分支名。
 我们在 <<_git_branching>>  会详细讨论分支和引用。
 
-现在，让我们在工程下创建一个新的 README 文件。
+现在，让我们在项目下创建一个新的 README 文件。
 如果之前并不存在这个文件，使用 `git status` 命令，你将看到一个新的未跟踪文件：
 
 [source,console]
@@ -106,7 +106,7 @@ Changes not staged for commit:
 ----
 
 文件 `CONTRIBUTING.md` 出现在 `Changes not staged for commit` 这行下面，说明已跟踪文件的内容发生了变化，但还没有放到暂存区。
-要暂存这次更新，需要运行 `git add` 命令。这是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。将这个命令理解为“添加内容到下一次提交中”而不是“将一个文件添加到工程中”要更加合适。(((git commands, add)))
+要暂存这次更新，需要运行 `git add` 命令。这是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。将这个命令理解为“添加内容到下一次提交中”而不是“将一个文件添加到项目中”要更加合适。(((git commands, add)))
 现在让我们运行 `git add` 将"CONTRIBUTING.md"放到暂存区，然后再看看 `git status` 的输出：
 
 [source,console]
@@ -237,7 +237,7 @@ doc/**/*.txt
 
 [TIP]
 ====
-GitHub 有一个十分详细的针对数十种工程及语言的 `.gitignore` 文件列表，你可以在 https://github.com/github/gitignore[] 找到它.
+GitHub 有一个十分详细的针对数十种项目及语言的 `.gitignore` 文件列表，你可以在 https://github.com/github/gitignore[] 找到它.
 ====
 
 [[_git_diff_staged]]

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -268,7 +268,7 @@ Normal merge conflict for 'index.html':
 Hit return to start merge resolution tool (opendiff):
 ----
 
-如果你想使用除默认工具（在这里 Git 使用 `opendiff` 做为默认的合并工具，因为作者在 Mac 上运行该程序）外的其他合并工具，你可以在 ``下列工具中（one of the following tools）`` 这句后面看到所有支持的合并工具。
+如果你想使用除默认工具（在这里 Git 使用 `opendiff` 做为默认的合并工具，因为作者在 Mac 上运行该程序）外的其他合并工具，你可以在 ``下列工具中（one of the following tools）'' 这句后面看到所有支持的合并工具。
 然后输入你喜欢的工具名字就可以了。
 
 [NOTE]

book/03-git-branching/sections/nutshell.asc

@@ -173,7 +173,7 @@ $ git log --oneline --decorate --graph --all
 由于 Git 的分支实质上仅是包含所指对象校验和（长度为 40 的 SHA-1 值字符串）的文件，所以它的创建和销毁都异常高效。
 创建一个新分支就像是往一个文件中写入 41 个字节（40 个字符和 1 个换行符），如此的简单能不快吗？
 
-这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的工程文件都复制一遍，并保存到一个特定的目录。
+这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。
 完成这样繁琐的过程通常需要好几秒钟，有时甚至需要好几分钟。所需时间的长短，完全取决于项目的规模。而在 Git 中，任何规模的项目都能在瞬间创建新分支。
 同时，由于每次提交都会记录父对象，所以寻找恰当的合并基础（译注：即共同祖先）也是同样的简单和高效。
 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。

book/05-distributed-git/1-distributed-git.asc

@@ -17,4 +17,4 @@ include::sections/maintaining.asc[]
 
 你现在能自如地使用 Git 为项目做出贡献、维护自己的项目或采纳其他用户的贡献了。
 恭喜你成为了一个高效的 Git 开发者！
-下一章中，你将会学到如何使用规模最大最流行的 Git 托管服务，Github。
+下一章中，你将会学到如何使用规模最大最流行的 Git 托管服务，GitHub。

book/05-distributed-git/sections/contributing.asc

@@ -408,8 +408,8 @@ To jessica@githost:simplegit.git
    fba9af8..cd685d1  featureB -> featureBee
 -----
 
-这称作一个 _引用表达式_。
-查看 <<_refspec>> 了解关于 Git 引用表达式与通过它们可以做的不同的事情的详细讨论。
+这称作一个 _引用规格_。
+查看 <<_refspec>> 了解关于 Git 引用规格与通过它们可以做的不同的事情的详细讨论。
 也要注意 `-u` 标记；这是 `--set-upstream` 的简写，该标记会为之后轻松地推送与拉取配置分支。
 
 紧接着，John 发邮件给 Jessica 说他已经推送了一些改动到 `featureA` 分支并要求她去验证它们。

book/05-distributed-git/sections/maintaining.asc

@@ -32,7 +32,7 @@ $ git checkout -b sc/ruby_client master
 ==== 应用来自邮件的补丁
 
 (((email, applying patches from)))
-如果你通过电子邮件收到了一个需要整合进入工程的补丁，你需要将其应用到特性分支中进行评估。
+如果你通过电子邮件收到了一个需要整合进入项目的补丁，你需要将其应用到特性分支中进行评估。
 有两种应用该种补丁的方法：使用 `git apply`，或者使用 `git am`。
 
 ===== 使用 `apply` 命令应用补丁
@@ -368,7 +368,7 @@ Git 项目还有一个从上一次发布中派生出来的 `maint` 分支来提
 Git 中的拣选类似于对特定的某次提交的变基。
 它会提取该提交的补丁，之后尝试将其重新应用到当前分支上。
 这种方式在你只想引入特性分支中的某个提交，或者特性分支中只有一个提交，而你不想运行变基时很有用。
-举个例子，假设你的工程提交历史类似：
+举个例子，假设你的项目提交历史类似：
 
 .拣选之前的示例历史。
 image::images/rebasing-1.png[拣选之前的示例历史。]

book/06-github/sections/2-contributing.asc

@@ -402,7 +402,7 @@ http://www.emoji-cheat-sheet.com
 
 ====== 图片
 
-从技术层面来说，这并不是 Github 风格 Markdown 的功能，但是也很有用。如果不想使用 Markdown 语法来插入图片，GitHub 允许你通过拖拽图片到文本区来插入图片。
+从技术层面来说，这并不是 GitHub 风格 Markdown 的功能，但是也很有用。如果不想使用 Markdown 语法来插入图片，GitHub 允许你通过拖拽图片到文本区来插入图片。
 
 [[_md_drag]]
 .通过拖拽的方式自动插入图片

book/06-github/sections/3-maintaining.asc

@@ -21,7 +21,7 @@ image::images/new-repo.png[``new repository'' 下拉列表.]
 image::images/newrepoform.png[``new repository'' 表单。]
 
 这里除了一个你必须要填的项目名，其他字段都是可选的。
-现在只需要点击 ``Create Repository'' 按钮，Duang!!! – 你就在 Github 上拥有了一个以 `<user>/<project_name>` 命名的新仓库了。
+现在只需要点击 ``Create Repository'' 按钮，Duang!!! – 你就在 GitHub 上拥有了一个以 `<user>/<project_name>` 命名的新仓库了。
 
 因为目前暂无代码，GitHub 会显示有关创建新版本库或者关联到一个已有的 Git 版本库的一些说明。
 我们不会在这里详细说明此项，如果你需要复习，去看 <<_git_basics_chapter>>._

book/07-git-tools/sections/stashing-cleaning.asc

@@ -5,7 +5,7 @@
 问题是，你不想仅仅因为过会儿回到这一点而为做了一半的工作创建一次提交。
 针对这个问题的答案是 `git stash` 命令。
 
-储藏会处理工作目录的脏的状态 - 即，修改的追踪文件与暂存改动 - 然后将未完成的修改保存到一个栈上，而你可以在任何时候重新应用这些改动。
+储藏会处理工作目录的脏的状态 - 即，修改的跟踪文件与暂存改动 - 然后将未完成的修改保存到一个栈上，而你可以在任何时候重新应用这些改动。
 
 ==== 储藏工作
 
@@ -136,7 +136,7 @@ $ git status -s
 M  index.html
 ----
 
-另一个经常使用储藏来做的事情是像储藏追踪文件一样储藏未追踪文件。默认情况下，`git stash` 只会储藏已经在索引中的文件。如果指定 `--include-untracked` 或 `-u` 标记，Git 也会储藏任何创建的未追踪文件。
+另一个经常使用储藏来做的事情是像储藏跟踪文件一样储藏未跟踪文件。默认情况下，`git stash` 只会储藏已经在索引中的文件。如果指定 `--include-untracked` 或 `-u` 标记，Git 也会储藏任何创建的未跟踪文件。
 
 [source,console]
 ----
@@ -225,7 +225,7 @@ Would remove test.o
 Would remove tmp/
 ----
 
-默认情况下，`git clean` 命令只会移除没有忽略的未追踪文件。任何与 `.gitiignore` 或其他忽略文件中的模式匹配的文件都不会被移除。如果你也想要移除那些文件，例如为了做一次完全干净的构建而移除所有由构建生成的 `.o` 文件，可以给 clean 命令增加一个 `-x` 选项。
+默认情况下，`git clean` 命令只会移除没有忽略的未跟踪文件。任何与 `.gitiignore` 或其他忽略文件中的模式匹配的文件都不会被移除。如果你也想要移除那些文件，例如为了做一次完全干净的构建而移除所有由构建生成的 `.o` 文件，可以给 clean 命令增加一个 `-x` 选项。
 
 [source,console]
 ----