Merge pull request #254 from networm/sync_05-distributed-git

Sync 05-distributed-git

Author: networm

book/05-distributed-git/images/centralized.png renamed to book/05-distributed-git/images/centralized_workflow.png

@@ -239,9 +239,11 @@ Date:   Fri May 29 16:01:27 2009 -0700
    removed invalid default value
 -----
 
-`issue54..origin/master` 语法是一个日志过滤器，要求 Git 只显示所有在后面分支（在本例中是 `origin/master`）但不在前面分支（在本例中是 `issue54`）的提交的列表。我们将会在 <<_commit_ranges>> 中详细介绍这个语法。
+`issue54..origin/master` 语法是一个日志过滤器，要求 Git 只显示所有在后面分支（在本例中是 `origin/master`）但不在前面分支（在本例中是 `issue54`）的提交的列表。
+我们将会在 <<_commit_ranges>> 中详细介绍这个语法。
 
-目前，我们可以从输出中看到有一个 John 生成的但是 Jessica 还没有合并入的提交。如果她合并 `origin/master`，也就是说将会修改她的本地工作的那个单个提交。
+目前，我们可以从输出中看到有一个 John 生成的但是 Jessica 还没有合并入的提交。
+如果她合并 `origin/master`，也就是说将会修改她的本地工作的那个单个提交。
 
 现在，Jessica 可以合并她的特性工作到她的 master 分支，合并 John 的工作（`origin/master`）进入她的 `master` 分支，然后再次推送回服务器。
 首先，为了整合所有这些工作她切换回她的 master 分支。
@@ -606,9 +608,9 @@ $ git commit
 $ git push myfork featureBv2
 -----
 
-`--squash` 选项接受被合并的分支上的所有工作，并将其压缩至一个非合并提交中。
-`--no-commit` 选项告诉 Git 不要自动记录一个提交。
-这允许你从另外的分支引入所有的改动然后在记录新提交前做更多的改动。
+`--squash` 选项接受被合并的分支上的所有工作，并将其压缩至一个变更集，使仓库变成一个真正的合并发生的状态，而不会真的生成一个合并提交。
+这意味着你的未来的提交将会只有一个父提交，并允许你引入另一个分支的所有改动，然后在记录一个新提交前做更多的改动。
+同样 `--no-commit` 选项在默认合并过程中可以用来延迟生成合并提交。
 
 现在你可以给维护者发送一条消息，表示你已经做了要求的修改然后他们可以在你的 `featureBv2` 分支上找到那些改动。
 
@@ -706,7 +708,33 @@ index 76f47bc..f9815f1 100644
 -----
 
 如果 IMAP 服务器不使用 SSL，最后两行可能没有必要，host 的值会是 `imap://` 而不是 `imaps://`。
-当那些设置完成后，可以使用 `git send-email` 将补丁序列放在特定 IMAP 服务器的 Drafts 文件夹中：
+当那些设置完成后，可以使用 `git imap-send` 将补丁序列放在特定 IMAP 服务器的 Drafts 文件夹中：
+
+[source,console]
+-----
+$ cat *.patch |git imap-send
+Resolving imap.gmail.com... ok
+Connecting to [74.125.142.109]:993... ok
+Logging in...
+sending 2 messages
+100% (2/2) done
+-----
+
+在这个时候，你应该能够到 Drafts 文件夹中，修改收件人字段为想要发送补丁的邮件列表，可能需要抄送给维护者或负责那个部分的人，然后发送。
+
+你也可以通过一个 SMTP 服务器发送补丁。
+同之前一样，你可以通过一系列的 `git config` 命令来分别设置选项，或者你可以手动地将它们添加到你的 `~/.gitconfig` 文件的 sendmail 区块：
+
+[source,ini]
+-----
+[sendemail]
+  smtpencryption = tls
+  smtpserver = smtp.gmail.com
+  smtpuser = [email protected]
+  smtpserverport = 587
+-----
+
+当这完成后，你可以使用 `git send-email` 发送你的补丁：
 
 [source,console]
 -----
@@ -739,8 +767,6 @@ References: <y>
 Result: OK
 -----
 
-在这个时候，应该能够到 Drafts 文件夹中，修改收件人字段为想要发送补丁的邮件列表，可能需要抄送给维护者或负责那个部分的人，然后寄出。
-
 ==== 总结
 
 这个部分介绍了处理可能会遇到的几个迥然不同类型的 Git 项目的一些常见的工作流程，介绍了帮助管理这个过程的一些新工具。

book/05-distributed-git/sections/contributing.asc

@@ -15,7 +15,7 @@
 若干个开发者则作为节点——也就是中心仓库的消费者——并且与其进行同步。
 
 .集中式工作流。
-image::images/centralized.png[集中式工作流。]
+image::images/centralized_workflow.png[集中式工作流。]
 
 这意味着如果两个开发者从中心仓库克隆代码下来，同时作了一些修改，那么只有第一个开发者可以顺利地把数据推送回共享服务器。
 第二个开发者在推送修改之前，必须先将第一个人的工作合并进来，这样才不会覆盖第一个人的修改。
@@ -29,7 +29,8 @@ John 完成了他的修改并推送到服务器。
 她被告知她的修改正通过非快进式（non-fast-forward）的方式推送，只有将数据抓取下来并且合并后方能推送。
 这种模式的工作流程的使用非常广泛，因为大多数人对其很熟悉也很习惯。
 
-当然这并不局限于小团队。利用 Git 的分支模型，通过同时在多个分支上工作的方式，即使是上百人的开发团队也可以很好地在单个项目上协作。
+当然这并不局限于小团队。
+利用 Git 的分支模型，通过同时在多个分支上工作的方式，即使是上百人的开发团队也可以很好地在单个项目上协作。
 
 [[_integration_manager]]
 ==== 集成管理者工作流

book/05-distributed-git/sections/distributed-workflows.asc

@@ -411,7 +411,8 @@ $ git config --global rerere.enabled true
 
 如果你需要和 rerere 的缓存交互，你可以使用 `git rerere` 命令。
 当单独调用它时，Git 会检查解决方案数据库，尝试寻找一个和当前任一冲突相关的匹配项并解决冲突（尽管当 `rerere.enabled` 被设置为 `true` 时会自动进行）。
-它也有若干子命令，可用来查看记录项，删除特定解决方案和清除缓存全部内容等。我们将在 <<_rerere>> 中详细探讨。
+它也有若干子命令，可用来查看记录项，删除特定解决方案和清除缓存全部内容等。
+我们将在 <<_rerere>> 中详细探讨。
 
 [[_tagging_releases]]
 ==== 为发布打标签