review v1

Author: zwpaper

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

@@ -1,17 +1,17 @@
 === 传输协议
 
 Git 可以通过两种主要的方式在版本库之间传输数据：“哑（dumb）”协议和“智能（smart）”协议。
-本节将会带你快速浏览这两种主要协议的操作过程。
+本节将会带你快速浏览这两种协议的主要操作过程。
 
 ==== 哑协议
 
 如果你建立一个使用 HTTP 协议访问并且是只读的版本库，那很可能使用的就是哑协议。
-这个协议之所以被称为“哑”协议，是因为在传输过程中，服务端不需要有针对 Git 特有的代码；抓取过程是一系列的 HTTP `GET` 请求，这种情况下，客户端可以假定服务端 Git 仓库中的布局。
+这个协议之所以被称为“哑”协议，是因为在传输过程中，服务端不需要有针对 Git 特有的代码；抓取过程是一系列 HTTP 的 `GET` 请求，这种情况下，客户端可以假定服务端 Git 仓库的布局。
 
 [NOTE]
 ====
 现在已经很少使用哑协议了。
-使用哑协议的版本库很难进行加密或者私有化，所以大多数 Git 服务器宿主（包括云端和本地）都会拒绝使用它。
+使用哑协议的版本库很难保证安全性和私有化，所以大多数 Git 服务器宿主（包括云端和本地）都会拒绝使用它。
 一般情况下都建议使用智能协议，我们会在后面进行介绍。
 ====
 
@@ -42,7 +42,7 @@ ref: refs/heads/master
 
 这说明在完成抓取后，你需要检出 `master` 分支。
 这时，你就可以开始漫游操作了。
-因为你的起点是在 `info/refs` 文件中所提到的 `ca82a6` commit 对象，所以你的开始操作就是获取它：
+因为你是从 `info/refs` 文件中所提到的 `ca82a6` commit 对象开始，所以你的首要操作是获取它：
 
 [source]
 ----
@@ -64,7 +64,7 @@ committer Scott Chacon <[email protected]> 1240030591 -0700
 changed the version number
 ----
 
-接下来，你还要再获取两个对象——`cfda3b`，含有我们刚刚获取的 commit 对象所指向内容的 tree 对象，和 `085bb3`，它的父提交记录；
+接下来，你还要再获取两个对象，一个是 `cfda3b`，含有我们刚刚获取的提交对象所指向内容的树对象，另一个是它的父级提交记录 `085bb3`：
 
 [source]
 ----
@@ -81,7 +81,7 @@ changed the version number
 (404 - Not Found)
 ----
 
-噢——看起来这个 tree 对象在服务端并不以松散格式对象存在，所以得到了 404 响应，代表在 HTTP 服务端没有找到该对象。
+噢——看起来这个树对象在服务端并不以松散格式对象存在，所以得到了 404 响应，代表在 HTTP 服务端没有找到该对象。
 这有好几个可能的原因——这个对象可能在替代版本库里面，或者在打包文件里面。
 Git 会首先检查任何列出的替代版本库：
 
@@ -125,21 +125,21 @@ P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 
 ==== 智能协议
 
-哑协议虽然很简单但效率不是很高，而且它不能实现从客户端向服务端发送数据。
-智能协议是更常用的传送数据的方法，但它需要在服务端运行一个进程，这也是 Git 的智能之处——它可以查看客户端有什么和需要什么内容，然后为它生成合适的打包文件。
-总共有两组用于传输数据的进程：一对用于上传数据，一对用于下载。
+哑协议虽然很简单但效率略低，且它不能从客户端向服务端发送数据。
+智能协议是更常用的传送数据的方法，但它需要在服务端运行一个进程，而这也是 Git 的智能之处——它可以读取客户端数据，明确指出其有什么和需要什么，并为它生成合适的包文件。
+总共有两组进程用于传输数据，分别负责上传和下载数据。
 
 ===== 上传数据
 
 (((git commands, send-pack)))(((git commands, receive-pack)))
 为了上传数据至远端，Git 使用 `send-pack` 和 `receive-pack` 进程。
-`send-pack` 进程运行在客户端上，它连接至远端运行的 `receive-pack` 进程。
+运行在客户端上的 `send-pack` 进程连接到远端运行的 `receive-pack` 进程。
 
 ====== SSH
 
-举例来说，你在你的项目上运行 `git push origin master`, 并且 `origin` 被定义为一个使用 SSH 协议的 URL。
+举例来说，在项目中使用命令 `git push origin master` 时, `origin` 是由基于 SSH 协议的 URL 所定义的。
 Git 会运行 `send-pack` 进程，它会通过 SSH 连接你的服务器。
-它尝试通过 SSH 在服务端运行命令，就像这样：
+它会尝试通过 SSH 在服务端执行命令，就像这样：
 
 [source,console]
 ----
@@ -172,10 +172,10 @@ agent=git/2:2.1.1+github-607-gfba4028 delete-refs
 0000
 ----
 
-Git 会为你正要更新的每一个引用发送一行数据，这一行包括了本行长度，旧 SHA 值，新 SHA 值和将要更新的引用。
+Git 会为每一个将要更新的引用发送一行数据，包括该行长度，旧 SHA 值，新 SHA 值和将要更新的引用。
 第一行也包括了客户端的容量。
 这里的全为 '0' 的 SHA-1 值表示之前没有过这个引用——因为你正要添加新的 experiment 引用。
-如果你在删除一个引用，你会看到相反的情况：右边的 SHA-1 值全为 '0'。
+删除引用时，将会看到相反的情况：右边的 SHA-1 值全为 '0'。
 
 接下来，客户端会发送一个打包文件，它包含了所有服务端还没有的对象。
 最后，服务端会以成功（或失败）响应：
@@ -187,7 +187,7 @@ Git 会为你正要更新的每一个引用发送一行数据，这一行包括
 
 ====== HTTP(S)
 
-这部分除了在连接握手的时候有一点不同，HTTPS 和 HTTP 在其它方面基本上都是相同的。
+HTTPS 与 HTTP 相比较，除了在“握手”过程略有不同外，其他基本相似。
 连接是从下面这个请求开始的：
 
 [source]
@@ -209,7 +209,7 @@ Git 会为你正要更新的每一个引用发送一行数据，这一行包括
 ----
 
 这个 `POST` 请求的负载是 `send-pack` 的输出和相应的打包文件。
-服务端在收到后相应地做出成功或失败的响应。
+服务端在收到请求后相应地作出成功或失败的响应。
 
 ===== 下载数据