Sync 03-git-branching rebasing

Author: networm

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

@@ -174,14 +174,16 @@ image::images/perils-of-rebasing-4.png[你将相同的内容又合并了一次
 
 此时如果你执行 `git log` 命令，你会发现有两个提交的作者、日期、日志居然是一样的，这会令人感到混乱。
 此外，如果你将这一堆又推送到服务器上，你实际上是将那些已经被变基抛弃的提交又找了回来，这会令人感到更加混乱。
-很明显对方并不想在提交历史中看到 `C4` 和 `C6`，因为之前就是她把这两个提交通过变基丢弃的。
+很明显对方并不想在提交历史中看到 `C4` 和 `C6`，因为之前就是他们把这两个提交通过变基丢弃的。
 
 [[_rebase_rebase]]
 ==== 用变基解决变基
 
-如果你 *真的* 遭遇了类似的处境，Git 还有一些高级魔法可以帮到你。如果团队中的某人强制推送并覆盖了一些你所基于的提交，你需要做的就是检查你做了哪些修改，以及他们覆盖了哪些修改。
+如果你 *真的* 遭遇了类似的处境，Git 还有一些高级魔法可以帮到你。
+如果团队中的某人强制推送并覆盖了一些你所基于的提交，你需要做的就是检查你做了哪些修改，以及他们覆盖了哪些修改。
 
-实际上，Git 除了对整个提交计算 SHA 校验和以外，也对本次提交所引入的修改计算了校验和——即 ``patch-id''。
+实际上，Git 除了对整个提交计算 SHA-1 校验和以外，也对本次提交所引入的修改计算了校验和——
+即 ``patch-id''。
 
 如果你拉取被覆盖过的更新并将你手头的工作基于此进行变基的话，一般情况下 Git 都能成功分辨出哪些是你的修改，并把它们应用到新分支上。
 
@@ -198,9 +200,11 @@ image::images/perils-of-rebasing-4.png[你将相同的内容又合并了一次
 .在一个被变基然后强制推送的分支上再次执行变基
 image::images/perils-of-rebasing-5.png[在一个被变基然后强制推送的分支上再次执行变基]
 
-要想上述方案有效，还需要对方在变基时确保 C4' 和 C4 是几乎一样的。否则变基操作将无法识别，并新建另一个类似 C4 的补丁（而这个补丁很可能无法整洁的整合入历史，因为补丁中的修改已经存在于某个地方了）。
+要想上述方案有效，还需要对方在变基时确保 C4' 和 C4 是几乎一样的。
+否则变基操作将无法识别，并新建另一个类似 C4 的补丁（而这个补丁很可能无法整洁的整合入历史，因为补丁中的修改已经存在于某个地方了）。
 
-在本例中另一种简单的方法是使用 `git pull --rebase` 命令而不是直接 `git pull`。又或者你可以自己手动完成这个过程，先 `git fetch`，再 `git rebase teamone/master`。
+在本例中另一种简单的方法是使用 `git pull --rebase` 命令而不是直接 `git pull`。
+又或者你可以自己手动完成这个过程，先 `git fetch`，再 `git rebase teamone/master`。
 
 如果你习惯使用 `git pull` ，同时又希望默认使用选项 `--rebase`，你可以执行这条语句 `git config --global pull.rebase true` 来更改 `pull.rebase` 的默认配置。