review v3

Author: zwpaper

book/10-git-internals/sections/transfer-protocols.asc

@@ -1,7 +1,7 @@
 === 传输协议
 
 Git 可以通过两种主要的方式在版本库之间传输数据：“哑（dumb）”协议和“智能（smart）”协议。
-本节将会带你快速浏览这两种协议的主要操作过程。
+本节将会带你快速浏览这两种协议的运作方式。
 
 ==== 哑协议
 
@@ -22,7 +22,7 @@ Git 可以通过两种主要的方式在版本库之间传输数据：“哑（d
 $ git clone http://server/simplegit-progit.git
 ----
 
-它做的第 1 件事情就是拉取 `info/refs` 文件。
+它做的第一件事就是拉取 `info/refs` 文件。
 这个文件是通过 `update-server-info` 命令生成的，这也解释了在使用HTTP传输时，必须把它设置为 `post-receive` 钩子的原因：
 
 [source]
@@ -32,7 +32,7 @@ ca82a6dff817ec66f44342007202690a93763949     refs/heads/master
 ----
 
 现在，你得到了一个远程引用和 SHA 值的列表。
-接下来，你要确定 HEAD 引用是什么，这样你就知道在完成后，什么应该被检出到工作目录：
+接下来，你要确定 HEAD 引用是什么，这样你就知道在完成后应该被检出到工作目录的内容：
 
 [source]
 ----
@@ -41,7 +41,7 @@ ref: refs/heads/master
 ----
 
 这说明在完成抓取后，你需要检出 `master` 分支。
-这时，你就可以开始漫游操作了。
+这时，你就可以开始感受一下这个过程了。
 因为你是从 `info/refs` 文件中所提到的 `ca82a6` 提交对象开始的，所以你的首要操作是获取它：
 
 [source]
@@ -64,7 +64,7 @@ committer Scott Chacon <[email protected]> 1240030591 -0700
 changed the version number
 ----
 
-接下来，你还要再获取两个对象，一个是 `cfda3b`，含有我们刚刚获取的提交对象所指向内容的树对象，另一个是它的父提交 `085bb3`：
+接下来，你还要再获取两个对象，一个是树对象 `cfda3b`，它包含有我们刚刚获取的提交对象所指向的内容，另一个是它的父提交 `085bb3`：
 
 [source]
 ----
@@ -121,12 +121,12 @@ P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 
 现在你也有了你的树对象，你可以继续在提交记录上漫游。
 它们全部都在这个你刚下载的包文件里面，所以你不用继续向服务端请求更多下载了。
-由于刚开始下载的 HEAD 引用指向 `master` 分支，Git 会将它检出到工作目录。
+Git 会将开始时下载的 HEAD 引用所指向的 `master` 分支检出到工作目录。
 
 ==== 智能协议
 
 哑协议虽然很简单但效率略低，且它不能从客户端向服务端发送数据。
-智能协议是更常用的传送数据的方法，但它需要在服务端运行一个进程，而这也是 Git 的智能之处——它可以读取客户端数据，明确指出其有什么和需要什么，并为它生成合适的包文件。
+智能协议是更常用的传送数据的方法，但它需要在服务端运行一个进程，而这也是 Git 的智能之处——它可以读取本地数据，理解客户端有什么和需要什么，并为它生成合适的包文件。
 总共有两组进程用于传输数据，它们分别负责上传和下载数据。
 
 ===== 上传数据
@@ -151,11 +151,11 @@ agent=git/2:2.1.1+github-607-gfba4028 delete-refs
 0000
 ----
 
-`git-receive-pack` 命令会立即为它所拥有的每一个引用响应一行——在这个例子中，就只有 `master` 分支和它的SHA值。
-第 1 行响应中也包含了一个服务端容量的列表（这里是 `report-status`、`delete-refs` 和一些其它的，包括客户端的识别码）。
+`git-receive-pack` 命令会立即为它所拥有的每一个引用发送一行响应——在这个例子中，就只有 `master` 分支和它的SHA值。
+第一行响应中也包含了一个服务端能力的列表（这里是 `report-status`、`delete-refs` 和一些其它的，包括客户端的识别码）。
 
-每一行以一个 4 位的十六进制值开始，用于指明本行的长度。
-你看到第 1 行以 005b 开始，这在十六进制中表示 91，意味着第 1 行有 91 字节。
+每一行以一个四位的十六进制值开始，用于指明本行的长度。
+你看到第一行以 005b 开始，这在十六进制中表示 91，意味着第一行有 91 字节。
 下一行以 003e 起始，也就是 62，所以下面需要读取 62 字节。
 再下一行是 0000，表示服务端已完成了发送引用列表过程。
 
@@ -173,7 +173,7 @@ agent=git/2:2.1.1+github-607-gfba4028 delete-refs
 ----
 
 Git 会为每一个将要更新的引用发送一行数据，包括该行长度，旧 SHA 值，新 SHA 值和将要更新的引用。
-第一行也包括了客户端的容量。
+第一行也包括了客户端的能力。
 这里的全为 '0' 的 SHA-1 值表示之前没有过这个引用——因为你正要添加新的 experiment 引用。
 删除引用时，将会看到相反的情况：右边的 SHA-1 值全为 '0'。
 
@@ -208,8 +208,8 @@ HTTPS 与 HTTP 相比较，除了在“握手”过程略有不同外，其他
 => POST http://server/simplegit-progit.git/git-receive/pack
 ----
 
-这个 `POST` 请求的负载是 `send-pack` 的输出和相应的包文件。
-服务端在收到请求后相应地作出成功或失败的响应。
+这个 `POST` 请求的内容是 `send-pack` 的输出和相应的包文件。
+服务端在收到请求后相应地作出成功或失败的 HTTP 响应。
 
 ===== 下载数据
 
@@ -238,7 +238,7 @@ $ ssh -x git@server "git-upload-pack 'simplegit-progit.git'"
 0000
 ----
 
-这与 `receive-pack` 的响应很相似，但是这里所包含的容量是不同的。
+这与 `receive-pack` 的响应很相似，但是这里所包含的能力是不同的。
 而且它还包含 HEAD 引用所指向内容（`symref=HEAD:refs/heads/master`），这样如果客户端执行的是克隆，它就会知道要检出什么。
 
 这时候，`fetch-pack` 进程查看它自己所拥有的对象，并响应“want”和它需要的对象的 SHA 值。