From a62daac2b141dacab93c06eab64d644a526fabf4 Mon Sep 17 00:00:00 2001 From: ousugo Date: Fri, 5 Feb 2021 15:02:58 +0800 Subject: [PATCH 1/2] fix space --- book/07-git-tools/sections/reset.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 43ead693..c84120ae 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -279,7 +279,7 @@ image::images/reset-squash-r3.png[] 运行 `git checkout [branch]` 与运行 `git reset --hard [branch]` 非常相似，它会更新所有三棵树使其看起来像 `[branch]`，不过有两点重要的区别。 首先不同于 `reset --hard`，`checkout` 对工作目录是安全的，它会通过检查来确保不会将已更改的文件弄丢。 -其实它还更聪明一些。它会在工作目录中先试着简单合并一下，这样所有_还未修改过的_文件都会被更新。 +其实它还更聪明一些。它会在工作目录中先试着简单合并一下，这样所有 _还未修改过的_ 文件都会被更新。 而 `reset --hard` 则会不做检查就全面地替换所有东西。 第二个重要的区别是 `checkout` 如何更新 HEAD。 @@ -290,7 +290,7 @@ image::images/reset-squash-r3.png[] 而如果我们运行 `git checkout master` 的话，`develop` 不会移动，HEAD 自身会移动。 现在 HEAD 将会指向 `master`。 -所以，虽然在这两种情况下我们都移动 HEAD 使其指向了提交 A，但_做法_是非常不同的。 +所以，虽然在这两种情况下我们都移动 HEAD 使其指向了提交 A，但 _做法_ 是非常不同的。 `reset` 会移动 HEAD 分支的指向，而 `checkout` 则移动 HEAD 自身。 image::images/reset-checkout.png[] From acc6747dad470d4e7c38dd8adbb697fa2e8bc80c Mon Sep 17 00:00:00 2001 From: ousugo Date: Mon, 23 Dec 2024 02:28:59 +0800 Subject: [PATCH 2/2] Optimize translation, resolve #481 --- book/05-distributed-git/sections/contributing.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 981d88cb..5fff1616 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -69,7 +69,7 @@ Git 项目要求一个更详细的解释，包括做改动的动机和它的实 如果必要的话，加入更详细的解释文字。在大概 72 个字符的时候换行。 在某些情形下，第一行被当作一封电子邮件的标题，剩下的文本作为正文。 分隔摘要与正文的空行是必须的（除非你完全省略正文）， -如果你将两者混在一起，那么类似变基等工具无法正常工作。 +如果你将两者混在一起，那么在使用例如变基这样的工具时，它们会生成难以阅读的输出，让人困惑。 使用指令式的语气来编写提交信息：使用“Fix bug”而非“Fixed bug”或“Fixes bug”。 此约定与 git merge 和 git revert 命令生成提交说明相同。