Merge pull request #232 from networm/09-git-and-other-scms_client-p4_review

09-git-and-other-scms client-p4 review

Author: networm

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

@@ -39,20 +39,20 @@ $ p4 -p localhost:1666 -u john passwd
 $ exit
 ----
 
-第一个命令将会打开一个 VI 编辑器来自定义用户，但是可以通过输入 `:wq` 加上回车来接受默认选项。
+第一个命令将会打开一个 VI 编辑器来自定义用户，但是可以通过输入 `:wq` 并回车来接受默认选项。
 第二个命令将会提示输入密码两次。
 这就是所有我们要通过终端提示符做的事情，所以现在可以退出当前会话了。
 
-接下来要跟着做的事就是告诉 Git 不要验证 SSL 证书。
+接下来要做的事就是告诉 Git 不要验证 SSL 证书。
 Git Fusion 镜像内置一个证书，但是域名并不匹配你的虚拟主机的 IP 地址，所以 Git 会拒绝 HTTPS 连接。
-如果安装会是永久的，查阅 Perforce Git Fusion 手册来安装一个不同的证书；然而，对于我们这个例子来说，这已经足够了。
+如果要进行永久安装，查阅 Perforce Git Fusion 手册来安装一个不同的证书；然而，对于我们这个例子来说，这已经足够了。
 
 [source,console]
 ----
 $ export GIT_SSL_NO_VERIFY=true
 ----
 
-现在我们可以测试所有东西是不是正常工作的。
+现在我们可以测试所有东西是不是正常工作。
 
 [source,console]
 ----
@@ -69,7 +69,7 @@ Checking connectivity... done.
 ----
 
 虚拟机镜像自带一个可以克隆的样例项目。
-这里我们通过 HTTPS 克隆，这会使用我们之前创建的 `john` 用户；Git 询问此次连接的凭证，但是凭证缓存会允许我们跳过这步之后的任意后续请求。
+这里我们会使用之前创建的 `john` 用户，通过 HTTPS 进行克隆；Git 询问此次连接的凭证，但是凭证缓存会允许我们跳过这步之后的任意后续请求。
 
 ====== Fusion 配置
 
@@ -98,7 +98,7 @@ $ tree
 ----
 
 `objects` 目录被 Git Fusion 内部用来双向映射 Perforce 对象与 Git 对象，你不必弄乱那儿的任何东西。
-在这个目录中有一个全局的 `p4gf_config` 文件，每个仓库中也会有一份 - 是那些配置文件决定了 Git Fusion 的行为。
+在这个目录中有一个全局的 `p4gf_config` 文件，每个仓库中也会有一份 - 这些配置文件决定了 Git Fusion 的行为。
 让我们看一下根目录下的文件：
 
 [source,ini]
@@ -144,7 +144,7 @@ view = //depot/Talkhouse/main-dev/... ...
 ----
 
 这是一个 Perforce 分支与一个 Git 分支的映射。
-这个区块可以命名成你喜欢的名字，只要保证名字是唯一的即可。
+这个区块可以被命名成你喜欢的名字，只要保证名字是唯一的即可。
 `git-branch-name` 允许你将在 Git 下显得笨重的仓库路径转换为更友好的名字。
 `view` 选项使用标准视图映射语法控制 Perforce 文件如何映射到 Git 仓库。
 可以指定一个以上的映射，就像下面的例子：
@@ -160,7 +160,7 @@ view = //depot/project1/main/... project1/...
 通过这种方式，如果正常工作空间映射包含对目录结构的修改，可以将其复制为一个 Git 仓库。
 
 最后一个我们讨论的文件是 `users/p4gf_usermap`，它将 Perforce 用户映射到 Git 用户，但你可能不会需要它。
-当从一个 Perforce 变更集转换为一个 Git 提交时，Git Fusion 的默认行为是去查找 Perforce 用户，然后把邮箱地址与全名存储在 Git 中的 author/commiter 字段中。
+当从一个 Perforce 变更集转换为一个 Git 提交时，Git Fusion 的默认行为是去查找 Perforce 用户，然后把邮箱地址与全名存储在 Git 的 author/commiter 字段中。
 当反过来转换时，默认的行为是根据存储在 Git 提交中 author 字段中的邮箱地址来查找 Perforce 用户，然后以该用户提交变更集（以及权限的应用）。
 大多数情况下，这个行为工作得很好，但是考虑下面的映射文件：
 
@@ -218,7 +218,7 @@ $ git log --oneline --decorate --graph --all
 这发生在服务器端本地，所以会相当快，但是如果有很多历史，那么它还是会花费一些时间。
 后来的抓取会做增量转换，所以会感觉更像 Git 的本地速度。
 
-如你所见，我们的仓库看起来像之前工作过的任何一个 Git 仓库了。
+如你所见，我们的仓库看起来像之前使用过的任何一个 Git 仓库了。
 这里有三个分支，Git 已经帮助创建了一个跟踪 `origin/master` 的本地 `master` 分支。
 让我们做一些工作，创建几个新提交：
 
@@ -309,14 +309,14 @@ Perforce 没有存储 `1` 和 `2` 提交的命名分支，所以它在 `.git-fus
 这并不是说扔给 Perforce 任何东西都会高兴 - 如果你尝试重写已经推送的历史，Git Fusion 会拒绝它 - 虽然 Git Fusion 尽力让你感觉是原生的。
 你甚至可以使用 Git 子模块（尽管它们对 Perforce 用户看起来很奇怪），合并分支（在 Perforce 这边会被记录了一次整合）。
 
-如果不能说服你的服务器的管理员设置 Git Fusion，依然有一种方式来一起使用这两个工具。
+如果不能说服你的服务器管理员设置 Git Fusion，依然有一种方式来一起使用这两个工具。
 
 ===== Git-p4
 
 (((git commands, p4)))
-Git-p4 是 Git 与 Perforce 之间双向桥接。
-它完全运行在你的 Git 仓库内，所以你不需要任何一种接触到 Perforce 服务器的权限（当然除了用户验证）。
-Git-p4 并不像 Git Fusion 一样灵活或完整，但是它允许你做大部分不需要修改服务器环境的事情。
+Git-p4 是 Git 与 Perforce 之间的双向桥接。
+它完全运行在你的 Git 仓库内，所以你不需要任何访问 Perforce 服务器的权限（当然除了用户验证）。
+Git-p4 并不像 Git Fusion 一样灵活或完整，但是它允许你在无需修改服务器环境的情况下，做大部分想做的事情。
 
 [NOTE]
 ======
@@ -326,7 +326,7 @@ Git-p4 并不像 Git Fusion 一样灵活或完整，但是它允许你做大部
 
 ====== 设置
 
-出于演示的目的，我们将会从上面演示的 Git Fusion OVA 运行 Perforce 服务器，但是我们会绕过 Git Fusion 服务器然后直接到达 Perforce 版本管理。
+出于演示的目的，我们将会从上面演示的 Git Fusion OVA 运行 Perforce 服务器，但是我们会绕过 Git Fusion 服务器然后直接进行 Perforce 版本管理。
 
 为了使用 `p4` 命令行客户端（git-p4 依赖项），你需要设置两个环境变量：
 
@@ -348,7 +348,7 @@ Initialized empty Git repository in /private/tmp/www-shallow/.git/
 Doing initial import of //depot/www/live/ from revision #head into refs/remotes/p4/master
 ----
 
-这样会创建出一种在 Git 中名为 ``shallow'' 克隆；只有最新版本的 Perforce 被导入至 Git；记住，Perforce 并未被设计成给每一个用户每一个版本。
+这样会创建出一种在 Git 中名为 ``shallow'' 克隆；只有最新版本的 Perforce 被导入至 Git；记住，Perforce 并未被设计成给每一个用户一个版本。
 使用 Git 作为 Perforce 客户端这样就足够了，但是为了其他目的的话这样可能不够。
 
 完成之后，我们就有一个全功能的 Git 仓库：
@@ -422,9 +422,9 @@ Applying: Change page title
 ----
 
 从输出中可能大概得知，`git p4 rebase` 是 `git p4 sync` 接着 `git rebase p4/master` 的快捷方式。
-它比那更聪明一些，特别是工作在多个分支时，但这是一个好的进步。
+它比那更聪明一些，特别是工作在多个分支时，但这是一个进步。
 
-现在我们的历史再次是直线，我们准备好我们的改动贡献回 Perforce。
+现在我们的历史再次是线性的，我们准备好我们的改动贡献回 Perforce。
 `git p4 submit` 命令会尝试在 `p4/master` 与 `master` 之间的每一个 Git 提交创建一个新的 Perforce 修订版本。
 运行它会带我们到最爱的编辑器，文件内容看起来像是这样：
 
@@ -590,7 +590,7 @@ $ git log --oneline --all --graph --decorate
 * 70eaf78 Initial import of //depot/www/live/ from the state at revision #head
 ----
 
-我们的历史变成直线了，就像在提交前刚刚变基过（实际上也是这样）。
+我们的历史变成线性了，就像在提交前刚刚变基过（实际上也是这样）。
 这意味着你可以在 Git 这边自由地创建、工作、扔掉与合并分支而不用害怕你的历史会变得与 Perforce 不兼容。
 如果你可以变基它，你就可以将它贡献到 Perforce 服务器。
 
@@ -658,12 +658,12 @@ $ git clone --detect-branches //depot/project@all .
 
 为了创建与整合分支，你不得不使用一个 Perforce 客户端。
 Git-p4 只能同步或提交已有分支，并且它一次只能做一个线性的变更集。
-如果你在 Git 中合并两个分支并尝度提交新的变更集，所有这些会被记录为一串文件修改；关于哪个分支参数的元数据在整合中会丢失。
+如果你在 Git 中合并两个分支并尝试提交新的变更集，所有这些会被记录为一串文件修改；关于哪个分支参与的元数据在整合中会丢失。
 
 ===== Git 与 Perforce 总结
 
 Git-p4 将与 Perforce 服务器工作时使用 Git 工作流成为可能，并且它非常擅长这点。
 然而，需要记住的重要一点是 Perforce 负责源头，而你只是在本地使用 Git。
 在共享 Git 提交时要相当小心：如果你有一个其他人使用的远程仓库，不要在提交到 Perforce 服务器前推送任何提交。
 
-如果想要为源码管理自由地混合使用 Perforce 与 Git 作为客户端，可以说服服务器管理员安装 Git Fusion，Git Fusion 使 Git 作为 Perforce 服务器的头等版本管理客户端。
+如果想要为源码管理自由地混合使用 Perforce 与 Git 作为客户端，可以说服服务器管理员安装 Git Fusion，Git Fusion 使 Git 作为 Perforce 服务器的首级版本管理客户端。