修正第九章破折号

Author: liuxilu

book/09-git-and-other-scms/sections/client-p4.asc

@@ -99,7 +99,7 @@ $ tree
 ----
 
 `objects` 目录被 Git Fusion 内部用来双向映射 Perforce 对象与 Git 对象，你不必弄乱那儿的任何东西。
-在这个目录中有一个全局的 `p4gf_config` 文件，每个仓库中也会有一份 - 这些配置文件决定了 Git Fusion 的行为。
+在这个目录中有一个全局的 `p4gf_config` 文件，每个仓库中也会有一份——这些配置文件决定了 Git Fusion 的行为。
 让我们看一下根目录下的文件：
 
 [source,ini]
@@ -307,7 +307,7 @@ Perforce 没有存储 `1` 和 `2` 提交的命名分支，所以它在 `.git-fus
 如果你有（或者能获得）接触你的 Perforce 服务器的权限，那么 Git Fusion 是使 Git 与 Perforce 互相交流的很好的方法。
 这里包含了一点配置，但是学习曲线并不是很陡峭。
 这是本章中其中一个不会出现无法使用 Git 全部能力的警告的章节。
-这并不是说扔给 Perforce 任何东西都会高兴 - 如果你尝试重写已经推送的历史，Git Fusion 会拒绝它 - 虽然 Git Fusion 尽力让你感觉是原生的。
+这并不是说扔给 Perforce 任何东西都会高兴——如果你尝试重写已经推送的历史，Git Fusion 会拒绝它——虽然 Git Fusion 尽力让你感觉是原生的。
 你甚至可以使用 Git 子模块（尽管它们对 Perforce 用户看起来很奇怪），合并分支（在 Perforce 这边会被记录了一次整合）。
 
 如果不能说服你的服务器管理员设置 Git Fusion，依然有一种方式来一起使用这两个工具。

book/09-git-and-other-scms/sections/client-svn.asc

@@ -23,7 +23,7 @@ Subversion 桥接就是进入 DVCS 世界的诱饵。
 
 不要重写你的历史然后尝试再次推送，同时也不要推送到一个平行的 Git 仓库来与其他使用 Git 的开发者协作。
 Subversion 只能有一个线性的历史，弄乱它很容易。
-如果你在一个团队中工作，其中有一些人使用 SVN 而另一些人使用 Git，你需要确保每个人都使用 SVN 服务器来协作 - 这样做会省去很多麻烦。
+如果你在一个团队中工作，其中有一些人使用 SVN 而另一些人使用 Git，你需要确保每个人都使用 SVN 服务器来协作——这样做会省去很多麻烦。
 
 ===== 设置
 
@@ -40,7 +40,7 @@ $ mkdir /tmp/test-svn
 $ svnadmin create /tmp/test-svn
 ----
 
-然后，允许所有用户改变版本属性 - 最容易的方式是添加一个返回值为 0 的 `pre-revprop-change` 脚本。
+然后，允许所有用户改变版本属性——最容易的方式是添加一个返回值为 0 的 `pre-revprop-change` 脚本。
 
 [source,console]
 ----
@@ -73,7 +73,7 @@ Copied properties for revision 2.
 ----
 
 虽然这个操作可能只会花费几分钟，但如果你尝试拷贝原始的仓库到另一个非本地的远程仓库时，即使只有不到 100 个的提交，这个过程也可能会花费将近一个小时。
-Subversion 必须一次复制一个版本然后推送回另一个仓库 - 这低效得可笑，但却是做这件事唯一简单的方式。
+Subversion 必须一次复制一个版本然后推送回另一个仓库——这低效得可笑，但却是做这件事唯一简单的方式。
 
 ===== 开始
 
@@ -101,7 +101,7 @@ Checked out HEAD:
   file:///tmp/test-svn/trunk r75
 ----
 
-这相当于运行了两个命令 - `git svn init` 以及紧接着的 `git svn fetch` - 你提供的 URL 。
+这相当于运行了两个命令—— `git svn init` 以及紧接着的 `git svn fetch` ——你提供的 URL 。
 这会花费一些时间。
 测试项目只有 75 个左右的提交并且代码库并不是很大，但是 Git 必须一次一个地检出一个版本同时单独地提交它。
 对于有成百上千个提交的项目，这真的可能会花费几小时甚至几天来完成。
@@ -174,7 +174,7 @@ $ git commit -am 'Adding git-svn instructions to the README'
 ----
 
 接下来，你需要将改动推送到上游。
-注意这会怎样改变你使用 Subversion 的方式 - 你可以离线做几次提交然后一次性将它们推送到 Subversion 服务器。
+注意这会怎样改变你使用 Subversion 的方式——你可以离线做几次提交然后一次性将它们推送到 Subversion 服务器。
 要推送到一个 Subversion 服务器，运行 `git svn dcommit` 命令：
 
 [source,console]
@@ -286,7 +286,7 @@ First, rewinding head to replay your work on top of it...
 
 记住这一点很重要，因为结果是当你推送后项目的状态并不存在于你的电脑中。
 如果修改并未冲突但却是不兼容的，可能会引起一些难以诊断的问题。
-这与使用 Git 服务器并不同 - 在 Git 中，可以在发布前完全测试客户端系统的状态，然而在 SVN 中，你甚至不能立即确定在提交前与提交后的状态是相同的。
+这与使用 Git 服务器并不同——在 Git 中，可以在发布前完全测试客户端系统的状态，然而在 SVN 中，你甚至不能立即确定在提交前与提交后的状态是相同的。
 
 你也应该运行这个命令从 Subversion 服务器上拉取修改，即使你自己并不准备提交。
 可以运行 `git svn fetch` 来抓取新数据，但是 `git svn rebase` 会抓取并更新你本地的提交。
@@ -331,7 +331,7 @@ No changes between 71af502c214ba13123992338569f4669877f55fd and refs/remotes/ori
 Resetting to the latest refs/remotes/origin/trunk
 ----
 
-在一个合并过历史提交的分支上 `dcommit` 命令工作得很好，除了当你查看你的 Git 项目历史时，它并没有重写所有你在 `experiment` 分支上所做的任意提交 - 相反，所有这些修改显示一个单独合并提交的 SVN 版本中。
+在一个合并过历史提交的分支上 `dcommit` 命令工作得很好，除了当你查看你的 Git 项目历史时，它并没有重写所有你在 `experiment` 分支上所做的任意提交——相反，所有这些修改显示一个单独合并提交的 SVN 版本中。
 
 当其他人克隆那些工作时，他们只会看到一个被塞入了所有改动的合并提交，就像运行了 `git merge --squash`；他们无法看到修改从哪来或何时提交的信息。
 
@@ -360,7 +360,7 @@ r91 = f1b64a3855d3c8dd84ee0ef10fa89d27f1584302 (refs/remotes/origin/opera)
 
 ===== 切换活动分支
 
-Git 通过查找在历史中 Subversion 分支的头部来指出你的提交将会到哪一个分支 - 应该只有一个，并且它应该是在当前分支历史中最后一个有 `git-svn-id` 的。
+Git 通过查找在历史中 Subversion 分支的头部来指出你的提交将会到哪一个分支——应该只有一个，并且它应该是在当前分支历史中最后一个有 `git-svn-id` 的。
 
 如果想要同时在不止一个分支上工作，可以通过在导入的那个分支的 Subversion 提交开始来设置本地分支 `dcommit` 到特定的 Subversion 分支。
 如果想要一个可以单独在上面工作的 `opera` 分支，可以运行
@@ -376,8 +376,8 @@ $ git branch opera remotes/origin/opera
 记住尽管使用的是 `git merge` 来做这个操作，而且合并可能会比在 Subversion 中更容易一些（因为 Git 会为你自动地检测合适的合并基础），但这并不是一个普通的 Git 合并提交。
 你不得不将这个数据推送回一个 Subversion 服务器，Subversion 服务器不支持那些跟踪多个父结点的提交；所以，当推送完成后，它看起来会是一个将其他分支的所有提交压缩在一起的单独提交。
 在合并一个分支到另一个分支后，你并不能像 Git 中那样轻松地回到原来的分支继续工作。
-你运行的 `dcommit` 命令会将哪个分支被合并进来的信息抹掉，所以后续的合并基础计算会是错的 - dcommit 会使你的 `git merge` 结果看起来像是运行了 `git merge --squash`。
-不幸的是，没有一个好的方式来避免这种情形 - Subversion 无法存储这个信息，所以当使用它做为服务器时你总是会被它的限制打垮。
+你运行的 `dcommit` 命令会将哪个分支被合并进来的信息抹掉，所以后续的合并基础计算会是错的—— dcommit 会使你的 `git merge` 结果看起来像是运行了 `git merge --squash`。
+不幸的是，没有一个好的方式来避免这种情形—— Subversion 无法存储这个信息，所以当使用它做为服务器时你总是会被它的限制打垮。
 为了避免这些问题，应该在合并到主干后删除本地分支（本例中是 `opera`）。
 
 ===== Subversion 命令

book/09-git-and-other-scms/sections/client-tfs.asc

@@ -22,7 +22,7 @@ Libgit2 并不是一个完整的 Git 实现，为了弥补差距 git-tfs 实际
 
 Git-tf（主页在 https://gittf.codeplex.com[]）是一个 Java 项目，因此它可以运行在任何一个有 Java 运行时环境的电脑上。
 它通过 JGit（一个 Git 的 JVM 实现）来与 Git 仓库交互，这意味着事实上它没有 Git 功能上的限制。
-然而，相对于 git-tfs 它对 TFVC 的支持是有限的 - 例如，它不支持分支。
+然而，相对于 git-tfs 它对 TFVC 的支持是有限的——例如，它不支持分支。
 
 所以每个工具都有优点和缺点，每个工具都有它适用的情况。
 我们在本书中将会介绍它们两个的基本用法。
@@ -107,7 +107,7 @@ C18 = 44cd729d8df868a8be20438fdeeefb961958b674
 
 注意 `--with-branches` 选项。
 Git-tfs 能够映射 TFVC 分支到 Git 分支，这个标记告诉它为每一个 TFVC 分支建立一个本地的 Git 分支。
-强烈推荐曾经在 TFS 中新建过分支或合并过分支的仓库使用这个标记，但是如果使用的服务器的版本比 TFS 2010 更老 - 在那个版本前，“分支”只是文件夹，所以 git-tfs 无法将它们与普通文件夹区分开。
+强烈推荐曾经在 TFS 中新建过分支或合并过分支的仓库使用这个标记，但是如果使用的服务器的版本比 TFS 2010 更老——在那个版本前，“分支”只是文件夹，所以 git-tfs 无法将它们与普通文件夹区分开。
 
 让我们看一下最终的 Git 仓库：
 
@@ -409,4 +409,4 @@ PS> git log --oneline --graph --decorate --all
 Git-tf 与 Git-tfs 都是与 TFVC 服务器交互的很好的工具。
 它们允许你在本地使用 Git 的能力，避免与中央 TFVC 服务器频繁交流，使你做为一个开发者的生活更轻松，而不用强制整个团队迁移到 Git。
 如果你在 Windows 上工作（那很有可能你的团队正在使用 TFS），你可能会想要使用 git-tfs，因为它的功能更完整，但是如果你在其他平台工作，你只能使用略有限制的 git-tf。
-像本章中大多数工具一样，你应当使用其中的一个版本系统作为主要的，而使用另一个做为次要的 - 不管是 Git 还是 TFVC 都可以做为协作中心，但不是两者都用。
+像本章中大多数工具一样，你应当使用其中的一个版本系统作为主要的，而使用另一个做为次要的——不管是 Git 还是 TFVC 都可以做为协作中心，但不是两者都用。

book/09-git-and-other-scms/sections/import-custom.asc

@@ -3,7 +3,7 @@
 
 (((git commands, fast-import)))
 (((Importing, from others)))
-如果你的系统不是上述中的任何一个，你需要在线查找一个导入器 - 针对许多其他系统有很多高质量的导入器，包括 CVS、Clear Case、Visual Source Safe，甚至是一个档案目录。
+如果你的系统不是上述中的任何一个，你需要在线查找一个导入器——针对许多其他系统有很多高质量的导入器，包括 CVS、Clear Case、Visual Source Safe，甚至是一个档案目录。
 如果没有一个工具适合你，需要一个不知名的工具，或者需要更大自由度的自定义导入过程，应当使用 `git fast-import`。
 这个命令从标准输入中读取简单指令来写入特定的 Git 数据。
 通过这种方式创建 Git 对象比运行原始 Git 命令或直接写入原始对象（查看 <<ch10-git-internals#ch10-git-internals>> 了解更多内容）更容易些。
@@ -30,8 +30,8 @@ current
 你的策略是一次访问一个快照，然后用每个目录中的内容创建提交，并且将每一个提交与前一个连接起来。
 
 如同我们在 <<ch08-customizing-git#r_an_example_git_enforced_policy>> 里做的，我们将会使用 Ruby 写这个，因为它是我们平常工作中使用的并且它很容易读懂。
-可以使用任何你熟悉的东西来非常轻松地写这个例子 - 它只需要将合适的信息打印到 `标准输出`。
-然而，如果你在 Windows 上，这意味着需要特别注意不要引入回车符到行尾 - git fast-import 非常特别地只接受换行符（LF）而不是 Windows 使用的回车换行符（CRLF）。
+可以使用任何你熟悉的东西来非常轻松地写这个例子——它只需要将合适的信息打印到 `标准输出`。
+然而，如果你在 Windows 上，这意味着需要特别注意不要引入回车符到行尾—— git fast-import 非常特别地只接受换行符（LF）而不是 Windows 使用的回车换行符（CRLF）。
 
 现在开始，需要进入目标目录中并识别每一个子目录，每一个都是你要导入为提交的快照。
 要进入到每个子目录中并为导出它打印必要的命令。
@@ -143,7 +143,7 @@ end
 ----
 
 剩下的工作就是指定每一个快照的文件内容。
-这很轻松，因为每一个目录都是一个快照 - 可以在目录中的每一个文件内容后打印 `deleteall` 命令。
+这很轻松，因为每一个目录都是一个快照——可以在目录中的每一个文件内容后打印 `deleteall` 命令。
 Git 将会适当地记录每一个快照：
 
 [source,ruby]
@@ -156,7 +156,7 @@ end
 ----
 
 注意：因为大多数系统认为他们的版本是从一个提交变化到另一个提交，fast-import 也可以为每一个提交执行命令来指定哪些文件是添加的、删除的或修改的与新内容是哪些。
-可以计算快照间的不同并只提供这些数据，但是这样做会很复杂 - 也可以把所有数据给 Git 然后让它为你指出来。
+可以计算快照间的不同并只提供这些数据，但是这样做会很复杂——也可以把所有数据给 Git 然后让它为你指出来。
 如果这更适合你的数据，查阅 `fast-import` man 帮助页来了解如何以这种方式提供你的数据。
 
 这种列出新文件内容或用新内容指定修改文件的格式如同下面的内容：
@@ -357,8 +357,8 @@ Date:   Mon Feb 3 01:00:00 2014 -0700
     imported from back_2014_02_03
 ----
 
-做得很好 - 一个漂亮、干净的 Git 仓库。
-要注意的一点是并没有检出任何东西 - 一开始你的工作目录内并没有任何文件。
+做得很好——一个漂亮、干净的 Git 仓库。
+要注意的一点是并没有检出任何东西——一开始你的工作目录内并没有任何文件。
 为了得到他们，你必须将分支重置到 `master` 所在的地方：
 
 [source,console]
@@ -370,5 +370,5 @@ $ ls
 README.md main.rb
 ----
 
-可以通过 `fast-import` 工具做很多事情 - 处理不同模式、二进制数据、多个分支与合并、标签、进度指示等等。
+可以通过 `fast-import` 工具做很多事情——处理不同模式、二进制数据、多个分支与合并、标签、进度指示等等。
 一些更复杂情形下的例子可以在 Git 源代码目录中的 `contrib/fast-import` 目录中找到。

book/09-git-and-other-scms/sections/import-p4.asc

@@ -70,7 +70,7 @@ Date:   Tue Jul 7 01:35:51 2009 -0800
 
 你可以看到 `git-p4` 在每一个提交里都留下了一个标识符。
 如果之后想要引用 Perforce 的修改序号的话，标识符保留在那里也是可以的。
-然而，如果想要移除标识符，现在正是这么做的时候 - 在你开始在新仓库中工作之前。
+然而，如果想要移除标识符，现在正是这么做的时候——在你开始在新仓库中工作之前。
 (((git commands, filter-branch)))
 可以使用 `git filter-branch` 将全部标识符移除。