Review 03-git-branching nutshell

Author: IceNature

book/03-git-branching/sections/nutshell.asc

@@ -8,7 +8,7 @@
 在进行提交操作时，Git 会保存一个提交对象（commit object）。知道了 Git 保存数据的方式，我们可以很自然的想到——该提交对象会包含一个指向暂存内容快照的指针。
 但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象，
 
-为了说得更加形象，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。
+为了更加形象地说明，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。
 暂存操作会为每一个文件计算校验和（使用我们在 <<_getting_started>> 中提到的 SHA-1 哈希算法），然后会把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 对象来保存它们），最终将校验和加入到暂存区域等待提交：
 
 [source,console]
@@ -23,12 +23,12 @@ $ git commit -m 'The initial commit of my project'
 现在，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照）、一个树对象（记录着目录结构和 blob 对象索引）以及一个提交对象（包含着指向前述树对象的指针和所有提交信息）。
 
 .首次提交对象及其树结构
-image::images/commit-and-tree.png[首次提交对象及其树结构.]
+image::images/commit-and-tree.png[首次提交对象及其树结构。]
 
 做些修改后再次提交，那么这次产生的提交对象会包含一个指向上次提交对象（父对象）的指针。
 
 .提交对象及其父对象
-image::images/commits-and-parents.png[提交对象及其父对象.]
+image::images/commits-and-parents.png[提交对象及其父对象。]
 
 Git 的分支，其实本质上仅仅是指向提交对象的可变指针。
 Git 的默认分支名字是 `master`。
@@ -43,7 +43,7 @@ Git 的 ``master'' 分支并不是一个特殊分支。(((master)))
 ====
 
 .分支及其提交历史
-image::images/branch-and-history.png[分支及其提交历史.]
+image::images/branch-and-history.png[分支及其提交历史。]
 
 [[_create_new_branch]]
 ==== 分支创建
@@ -72,7 +72,7 @@ image::images/two-branches.png[两个指向相同提交历史的分支。]
 因为 `git branch` 命令仅仅 _创建_ 一个新分支，并不会自动切换到新分支中去。
 
 .HEAD 指向当前所在的分支
-image::images/head-to-master.png[HEAD 指向当前所在的分支.]
+image::images/head-to-master.png[HEAD 指向当前所在的分支。]
 
 你可以简单地使用 `git log` 命令查看各个分支当前所指的对象。
 提供这一功能的参数是 `--decorate`。
@@ -102,7 +102,7 @@ $ git checkout testing
 这样 `HEAD` 就指向 `testing` 分支了。
 
 .HEAD 指向当前所在的分支
-image::images/head-to-testing.png[HEAD 指向当前所在的分支.]
+image::images/head-to-testing.png[HEAD 指向当前所在的分支。]
 
 那么，这样的实现方式会给我们带来什么好处呢？
 现在不妨再提交一次：
@@ -114,7 +114,7 @@ $ git commit -a -m 'made a change'
 ----
 
 .HEAD 分支随着提交操作自动向前移动
-image::images/advance-testing.png[HEAD 分支随着提交操作自动向前移动.]
+image::images/advance-testing.png[HEAD 分支随着提交操作自动向前移动。]
 
 如图所示，你的 `testing` 分支向前移动了，但是 `master` 分支却没有，它仍然指向运行 `git checkout` 时所指的对象。
 这就有意思了，现在我们切换回 `master` 分支看看：
@@ -125,7 +125,7 @@ $ git checkout master
 ----
 
 .检出时 HEAD 随之移动
-image::images/checkout-master.png[检出时 HEAD 随之移动.]
+image::images/checkout-master.png[检出时 HEAD 随之移动。]
 
 这条命令做了两件事。
 一是使 HEAD 指回 `master` 分支，二是将工作目录恢复成 `master` 分支所指向的快照内容。
@@ -155,7 +155,7 @@ $ git commit -a -m 'made other changes'
 
 [[divergent_history]]
 .项目分叉历史
-image::images/advance-master.png[项目分叉历史.]
+image::images/advance-master.png[项目分叉历史。]
 
 你可以简单地使用 `git log` 命令查看分叉历史。
 运行 `git log --oneline --decorate --graph --all` ，它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。
@@ -172,11 +172,11 @@ $ git log --oneline --decorate --graph --all
 ----
 
 由于 Git 的分支实质上仅是包含所指对象校验和（长度为 40 的 SHA-1 值字符串）的文件，所以它的创建和销毁都异常高效。
-创建一个新分支就像是往一个文件中写入 41 个字节（40 个字符和 1 个换行符），如此的简单能不快吗？
+创建一个新分支就相当于往一个文件中写入 41 个字节（40 个字符和 1 个换行符），如此的简单能不快吗？
 
 这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。
 完成这样繁琐的过程通常需要好几秒钟，有时甚至需要好几分钟。所需时间的长短，完全取决于项目的规模。而在 Git 中，任何规模的项目都能在瞬间创建新分支。
 同时，由于每次提交都会记录父对象，所以寻找恰当的合并基础（译注：即共同祖先）也是同样的简单和高效。
 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。
 
-接下来，让我们看看为什么你应该这么做？
+接下来，让我们看看你为什么应该这样做。