Merge pull request #393 from OlingCat/merge-pr

解决审校的冲突

Author: networm

B-embedding-git.asc

@@ -2,8 +2,8 @@
 [appendix]
 == 将 Git 嵌入你的应用
 
-假设你的应用程序的目标人群是开发者，如果它能够被整合进一些源码控制的功能，那真真是极好的。
-甚至对于一个例如文档编辑器之类的不是为开发者而设计的应用程序，它们也可能从版本控制系统中受益，并且 Git 的实现方式在很多情况下都表现得非常出色。
+假设你的应用程序的目标人群是开发者，如果它能够被整合进一些源码控制的功能，那真是极好的。
+甚至对于一个例如文档编辑器之类的不是为开发者而设计的应用程序，它们也可能从版本控制系统中受益，并且 Git 模块化的实现方式在很多情况下都表现得非常出色。
 
 如果你想将 Git 整合进你的应用程序的话，一般来说你有三种可能的选择：启动一个 shell 来使用 Git 的命令行工具；使用 Libgit2；或者使用 JGit。
 

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

@@ -1,13 +1,13 @@
 [[r_getting_a_repo]]
 === 获取 Git 仓库
 
-有两种取得 Git 项目仓库的方法。
-第一种是在现有项目或目录下导入所有文件到 Git 中；
-第二种是从一个服务器克隆一个现有的 Git 仓库。
+有两种获取 Git 项目仓库的主要方式。
+第一种是将已有项目或目录导入为 Git 仓库；
+第二种是从其它服务器克隆一个已存在的 Git 仓库。
 
-==== 在现有目录中初始化仓库
+==== 在已存在目录中初始化仓库
 
-如果你打算使用 Git 来对现有的项目进行管理，你只需要进入该项目目录并输入：
+如果你打算使用 Git 来对已有项目进行追踪，你需要进入项目目录并输入：
 
 [source,console]
 ----
@@ -18,8 +18,8 @@ $ git init
 但是，在这个时候，我们仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪。
 (参见 <<ch10-git-internals#ch10-git-internals>> 来了解更多关于到底 `.git` 文件夹中包含了哪些文件的信息。)(((git commands, init)))
 
-如果你是在一个已经存在文件的文件夹（而不是空文件夹）中初始化 Git 仓库来进行版本控制的话，你应该开始跟踪这些文件并提交。
-你可通过 `git add` 命令来实现对指定文件的跟踪，然后执行 `git commit` 提交：
+如果在一个已存在文件的文件夹（而非空文件夹）中进行版本控制，你应该开始追踪这些文件并进行初始提交。
+可以通过 `git add` 命令来指定所需的文件来进行追踪，然后执行 `git commit` ：
 
 [source,console]
 ----
@@ -28,8 +28,8 @@ $ git add LICENSE
 $ git commit -m 'initial project version'
 ----
 
-稍后我们再逐一解释每一条指令的意思。
-现在，你已经得到了一个实际维护（或者说是跟踪）着若干个文件的 Git 仓库。
+稍后我们再逐一解释这些指令的行为。
+现在，你已经得到了一个存在被追踪文件与初始提交的 Git 仓库。
 
 [[r_git_cloning]]
 ==== 克隆现有的仓库
@@ -40,8 +40,8 @@ $ git commit -m 'initial project version'
 当你执行 `git clone` 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。
 事实上，如果你的服务器的磁盘坏掉了，你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库（虽然可能会丢失某些服务器端的挂钩设置，但是所有版本的数据仍在，详见 <<ch04-git-server#r_git_on_the_server>> ）。
 
-克隆仓库的命令格式是 `git clone [url]` 。(((git commands, clone)))
-比如，要克隆 Git 的可链接库 libgit2，可以用下面的命令：
+克隆仓库的命令是 `git clone [url]` 。(((git commands, clone)))
+比如，要克隆 Git 的链接库 libgit2，可以用下面的命令：
 
 [source,console]
 ----
@@ -57,7 +57,7 @@ $ git clone https://github.com/libgit2/libgit2
 $ git clone https://github.com/libgit2/libgit2 mylibgit
 ----
 
-这将执行与上一个命令相同的操作，不过在本地创建的仓库名字变为 `mylibgit`。
+这将执行与上一条命令相同的操作，但目标目录名变为了 `mylibgit`。
 
 Git 支持多种数据传输协议。
 上面的例子使用的是 `https://` 协议，不过你也可以使用 `git://` 协议或者使用 SSH 传输协议，比如 `user@server:path/to/repo.git` 。

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

@@ -4,20 +4,20 @@
 接下来，对这些文件做些修改，在完成了一个阶段的目标之后，提交本次更新到仓库。
 
 请记住，你工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。
-已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。
-工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。
+已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能是未修改，已修改或已放入暂存区。
+工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入暂存区。
 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。
 
 编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。
-我们逐步将这些修改过的文件放入暂存区，然后提交所有暂存了的修改，如此反复。所以使用 Git 时文件的生命周期如下：
+我们逐步将这些修改过的文件放入暂存区，然后提交所有暂存了的修改，如此反复。
 
 .文件的状态变化周期
 image::images/lifecycle.png[Git 下文件生命周期图。]
 
 [[r_checking_status]]
 ==== 检查当前文件状态
 
-要查看哪些文件处于什么状态，可以用 `git status` 命令。(((git commands, status)))
+可以用 `git status` 命令查看哪些文件处于什么状态。(((git commands, status)))
 如果在克隆仓库后立即使用此命令，会看到类似这样的输出：
 
 [source,console]
@@ -50,7 +50,7 @@ nothing added to commit but untracked files present (use "git add" to track)
 ----
 
 在状态报告中可以看到新建的 README 文件出现在 `Untracked files` 下面。
-未跟踪的文件意味着 Git 在之前的快照（提交）中没有这些文件；Git 不会自动将之纳入跟踪范围，除非你明明白白地告诉它“我需要跟踪该文件”，
+未跟踪的文件意味着 Git 在之前的快照（提交）中没有这些文件；Git 不会自动将之纳入跟踪范围，除非你明明白白地告诉它“我需要跟踪该文件”。
 这样的处理让你不必担心将生成的二进制文件或其它不想被跟踪的文件包含进来。
 不过现在的例子中，我们确实想要跟踪管理 README 这个文件。
 
@@ -79,7 +79,7 @@ Changes to be committed:
 ----
 
 只要在 `Changes to be committed` 这行下面的，就说明是已暂存状态。
-如果此时提交，那么该文件此时此刻的版本将被留存在历史记录中。
+如果此时提交，那么该文件在你运行 `git add` 时的版本将被留存在历史记录中。
 你可能会想起之前我们使用 `git init` 后就运行了 `git add (files)` 命令，开始跟踪当前目录下的文件。(((git commands, init)))(((git commands, add)))
 `git add` 命令使用文件或目录的路径作为参数；如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。
 
@@ -125,7 +125,7 @@ Changes to be committed:
 ----
 
 现在两个文件都已暂存，下次提交时就会一并记录到仓库。
-假设此时，你想要在 `CONTRIBUTING.md` 里再加条注释，
+假设此时，你想要在 `CONTRIBUTING.md` 里再加条注释。
 重新编辑存盘后，准备好提交。
 不过且慢，再运行 `git status` 看看：
 
@@ -151,7 +151,7 @@ Changes not staged for commit:
 怎么回事？
 现在 `CONTRIBUTING.md` 文件同时出现在暂存区和非暂存区。
 这怎么可能呢？
-好吧，实际上 Git 只不过暂存了你运行 `git add` 命令时的版本，
+好吧，实际上 Git 只不过暂存了你运行 `git add` 命令时的版本。
 如果你现在提交，`CONTRIBUTING.md` 的版本是你最后一次运行 `git add` 命令时的那个版本，而不是你运行 `git commit` 时，在工作目录中的当前版本。
 所以，运行了 `git add` 之后又作了修订的文件，需要重新运行 `git add` 把最新版本重新暂存起来：
 
@@ -170,8 +170,8 @@ Changes to be committed:
 ==== 状态简览
 
 `git status` 命令的输出十分详细，但其用语有些繁琐。
-如果你使用 `git status -s` 命令或 `git status --short` 命令，你将得到一种更为紧凑的格式输出。
-运行 `git status -s` ，状态报告输出如下：
+Git 有一个选项可以帮你缩短状态命令的输出，这样可以以简洁的方式查看更改。
+如果你使用 `git status -s` 命令或 `git status --short` 命令，你将得到一种格式更为紧凑的输出。
 
 [source,console]
 ----
@@ -184,17 +184,17 @@ M  lib/simplegit.rb
 ----
 
 新添加的未跟踪文件前面有 `??` 标记，新添加到暂存区中的文件前面有 `A` 标记，修改过的文件前面有 `M` 标记。
-你可能注意到了 `M` 有两个可以出现的位置，出现在右边的 `M` 表示该文件被修改了但是还没放入暂存区，出现在靠左边的 `M` 表示该文件被修改了并放入了暂存区。
-例如，上面的状态报告显示： `README` 文件在工作区被修改了但是还没有将修改后的文件放入暂存区,`lib/simplegit.rb` 文件被修改了并将修改后的文件放入了暂存区。
+你可能注意到了 `M` 有两个可以出现的位置，出现在右边的 `M` 表示该文件被修改了但是还没被放入暂存区，出现在靠左边的 `M` 表示该文件被修改了并被放入了暂存区。
+例如，上面的状态报告显示： `README` 文件在工作区被修改了但是还没有将修改后的文件放入暂存区,`lib/simplegit.rb` 文件被修改了并已将修改后的文件放入了暂存区。
 而 `Rakefile` 在工作区被修改并提交到暂存区后又在工作区中被修改了，所以在暂存区和工作区都有该文件被修改了的记录。
 
 [[r_ignoring]]
 ==== 忽略文件
 
 一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。
 通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。
-在这种情况下，我们可以创建一个名为 `.gitignore` 的文件，列出要忽略的文件模式。
-来看一个实际的例子：
+在这种情况下，我们可以创建一个名为 `.gitignore` 的文件，列出要忽略的文件的模式。
+来看一个实际的 `.gitignore` 例子：
 
 [source,console]
 ----
@@ -245,16 +245,16 @@ doc/**/*.pdf
 
 [TIP]
 ====
-GitHub 有一个十分详细的针对数十种项目及语言的 `.gitignore` 文件列表，你可以在 https://github.com/github/gitignore[] 找到它.
+GitHub 有一个十分详细的针对数十种项目及语言的 `.gitignore` 文件列表，你可以在 https://github.com/github/gitignore[] 找到它。
 ====
 
 [[r_git_diff_staged]]
 ==== 查看已暂存和未暂存的修改
 
 如果 `git status` 命令的输出对于你来说过于模糊，你想知道具体修改了什么地方，可以用 `git diff` 命令。(((git commands, diff)))
 稍后我们会详细介绍 `git diff`，你可能通常会用它来回答这两个问题：当前做的哪些更新还没有暂存？
-有哪些更新已经暂存起来准备好了下次提交？
-尽管 `git status` 已经通过在相应栏下列出文件名的方式回答了这个问题，`git diff` 将通过文件补丁的格式显示具体哪些行发生了改变。
+有哪些更新已经暂存起来准备好下次提交？
+虽然 `git status` 已经通过在相应栏下列出文件名的方式回答了这个问题，但 `git diff` 将通过文件补丁的格式更加具体地显示哪些行发生了改变。
 
 假如再次修改 README 文件后暂存，然后编辑 `CONTRIBUTING.md` 文件后先不暂存，
 运行 `status` 命令将会看到：
@@ -296,10 +296,11 @@ index 8ebb991..643e24f 100644
  that highlights your work in progress (and note in the PR title that it's
 ----
 
-此命令比较的是工作目录中当前文件和暂存区域快照之间的差异，
+此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。
 也就是修改之后还没有暂存起来的变化内容。
 
-若要查看已暂存的将要添加到下次提交里的内容，可以用 `git diff --cached` 命令。（Git 1.6.1 及更高版本还允许使用 `git diff --staged`，效果是相同的，但更好记些。）
+若要查看已暂存的将要添加到下次提交里的内容，可以用 `git diff --staged` 命令。
+这条命令将比对已暂存文件与最后一次提交的文件差异：
 
 [source,console]
 ----
@@ -316,7 +317,7 @@ index 0000000..03902a1
 请注意，git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。
 所以有时候你一下子暂存了所有更新过的文件后，运行 `git diff` 后却什么也没有，就是这个原因。
 
-像之前说的，暂存 `CONTRIBUTING.md` 后再编辑，运行 `git status` 会看到暂存前后的两个版本。
+像之前说的，暂存 `CONTRIBUTING.md` 后再编辑，可以使用 `git status` 查看已被暂存的修改或未被暂存的修改。
 如果我们的环境（终端输出）看起来如下：
 
 [source,console]
@@ -378,7 +379,8 @@ index 8ebb991..643e24f 100644
 .Git Diff 的插件版本
 ====
 在本书中，我们使用 `git diff` 来分析文件差异。
-但是，如果你喜欢通过图形化的方式或其它格式输出方式的话，可以使用 `git difftool` 命令来用 Araxis ，emerge 或 vimdiff 等软件输出 diff 分析结果。
+但是你也可以使用图形化的工具或外部 diff 工具来比较差异。
+可以使用 `git difftool` 命令来用 Araxis ，emerge 或 vimdiff 等软件（包括商业软件）输出 diff 的分析结果。
 使用 `git difftool --tool-help` 命令来看你的系统支持哪些 Git Diff 插件。
 ====
 
@@ -387,8 +389,8 @@ index 8ebb991..643e24f 100644
 
 现在的暂存区域已经准备妥当可以提交了。
 在此之前，请一定要确认还有什么修改过的或新建的文件还没有 `git add` 过，否则提交的时候不会记录这些还没暂存起来的变化。
-这些修改过的文件只保留在本地磁盘。
-所以，每次准备提交前，先用 `git status` 看下，是不是都已暂存起来了，(((git commands, status)))
+这些修改过但没有暂存的文件只保留在本地磁盘。
+所以，每次准备提交前，先用 `git status` 看下，你所需要的文件是不是都已暂存起来了，(((git commands, status)))
 然后再运行提交命令 `git commit`：(((git commands, commit)))
 
 [source,console]
@@ -436,7 +438,7 @@ $ git commit -m "Story 182: Fix benchmarks for speed"
 可以看到，提交后它会告诉你，当前是在哪个分支（`master`）提交的，本次提交的完整 SHA-1 校验和是什么（`463dc4f`），以及在本次提交中，有多少文件修订过，多少行添加和删改过。
 
 请记住，提交时记录的是放在暂存区域的快照。
-任何还未暂存的仍然保持已修改状态，可以在下次提交时纳入版本管理。
+任何还未暂存文件的仍然保持已修改状态，可以在下次提交时纳入版本管理。
 每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较。
 
 ==== 跳过使用暂存区域
@@ -463,6 +465,8 @@ $ git commit -a -m 'added new benchmarks'
 ----
 
 看到了吗？提交之前不再需要 `git add` 文件“CONTRIBUTING.md”了。
+这是因为 `-a` 选项使本次提交包含了所有修改过的文件。
+这很方便，但是要小心；有时这个选项会将不需要的文件添加到提交中。
 
 [[r_removing_files]]
 ==== 移除文件