From cc1a1184b22b2d796e3eea1c64ddaf78987f576f Mon Sep 17 00:00:00 2001 From: Jacob Zuo Date: Thu, 2 Nov 2017 20:02:10 -0500 Subject: [PATCH] revising ch.5 - history --- zh_cn/history.txt | 54 ++++++++++++++++++++++++++---------------------------- 1 file changed, 26 insertions(+), 28 deletions(-) diff --git a/zh_cn/history.txt b/zh_cn/history.txt index ae29e84..e342329 100644 --- a/zh_cn/history.txt +++ b/zh_cn/history.txt @@ -2,9 +2,9 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需要小心：只重写你独自拥有 的那部分。正如民族间会无休止的争论谁犯下了什么暴行一样，如果在另一个人的克隆 -里，历史版本与你的不同，当你们的树互操作时，你会遇到一致性方面的问题。 +里，历史版本与你的不同，当你们的树互操作时，你们会遇到一致性方面的问题。 -一些开发人员强烈地感觉历史应该永远不变，不好的部分也不变所有都不变。另一些觉 +一些开发人员强烈地感到历史应该永远不变，不好的部分也不变，所有都不变。另一些觉 得代码树在向外发布之前，应该整得漂漂亮亮的。Git同时支持两者的观点。像克隆，分 支和合并一样，重写历史只是Git给你的另一强大功能，至于如何明智地使用它，那是你 的事了。 @@ -40,8 +40,8 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 提交，100834是最新的提交。接下来可以在$EDITOR中： - 通过删除行来移去提交。 -- 通过为行重新排序行来重新排序提交。 -- 替换 `pick` 使用： +- 通过对几行记录重新排序，来重组提交顺序。 +- 替换 `pick` 命令： * `edit` 标记一个提交需要修订。 * `reword` 改变日志信息。 * `squash` 将一个提交与其前一个合并。 @@ -77,7 +77,7 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 与官方版本同步。在你准备好提交到中心分支之前，这个循环会重复几次。 但现在你本地Git克隆掺杂了你的改动和官方改动。你更期望在变更列表里，你所有的变 -更能够连续。 +更能够连续列出。 这就是上面提到的 *git rebase* 所做的工作。在很多情况下你可以使用 *--onto* 标 记以避免交互。 @@ -90,7 +90,7 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 === 重写历史 === -偶尔，你需要做一些代码控制，好比从正式的照片中去除一些人一样，需要从历史记录 +偶尔，你需要做一些代码控制——好比从正式的照片中去除一些人一样——你需要从历史记录 里面彻底的抹掉他们。例如，假设我们要发布一个项目，但由于一些原因，项目中的某 个文件不能公开。或许我把我的信用卡号记录在了一个文本文件里，而我又意外的把它 加入到了这个项目中。仅仅删除这个文件是不够的，因为从别的提交记录中还是可以访 @@ -101,10 +101,10 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 参见 *git help filter-branch* ，那里讨论了这个例子并给出一个更快的方法。一般 地， *filter-branch* 允许你使用一个单一命令来大范围地更改历史。 -此后，+.git/refs/original+目录描述操作之前的状态。检查命令filter-branch的确做 -了你想要做的，然后删除此目录，如果你想运行多次filter-branch命令。 +此后，+.git/refs/original+目录描述操作之前的状态。检查命令 *filter-branch* 的 +确做了你想要做的，然后删除此目录，如果你想运行多次filter-branch命令。 -最后，用你修订过的版本替换你的项目克隆，如果你想之后和它们交互的话。 +最后，如果你想之后和修订过的版本交互的话，记得用你修订过的版本替换你的项目克隆。 === 制造历史 === @@ -162,9 +162,9 @@ EOT $ git checkout master . -命令*git fast-export* 转换任意仓库到 *git fast-import* 格式，你可以研究其输 -出来写导出程序， 也以可读格式传送仓库。的确，这些命令可以发送仓库文本文件 -通过只接受文本的渠道。 +命令*git fast-export* 可将任意仓库转换成 *git fast-import* 格式，你可以研究其输 +出来写新的导出程序， 或以人类可以理解的格式转移仓库。的确，这些命令可以通过只接受文 +本的渠道来发送仓库文件。 === 哪儿错了？ === @@ -219,24 +219,22 @@ Git使用指定命令（通常是一个一次性的脚本）的返回值来决 中心系统排斥离线工作，也需要更昂贵的网络设施，特别是当开发人员增多的时候。最 重要的是，所有操作都一定程度变慢，一般在用户避免使用那些能不用则不用的高级命 令时。在极端的情况下，即使是最基本的命令也会变慢。当用户必须运行缓慢的命令的 -时候，由于工作流被打断，生产力降低。 +时候，由于工作流被打断，生产力就会降低。 -我有这些的一手经验。Git是我使用的第一个版本控制系统。我很快学会适应了它，用了 -它提供的许多功能。我简单地假设其他系统也是相似的：选择一个版本控制系统应该和 -选择一个编辑器或浏览器没啥两样。 +我有这方面的一手经验。Git是我使用的第一个版本控制系统。我很快学会适应了它，并 +使用了它提供的许多功能。我简单地假设其他系统也是相似的：选择一个版本控制系统应 +该和选择一个编辑器或浏览器没啥两样。 -在我之后被迫使用中心系统的时候，我被震惊了。我那有些脆弱的网络没给Git带来大麻 -烦，但是当它需要像本地硬盘一样稳定的时候，它使开发困难重重。另外，我发现我自 -己有选择地避免特定的命令，以避免踏雷，这极大地影响了我，使我不能按照我喜欢的 -方式工作。 +在我之后被迫使用中心系统的时候，我被震惊到了。我那有些脆弱的网络没给Git带来 +大麻烦，但是当它需要像本地硬盘一样稳定工作的时候，它使开发变得困难重重。另 +外，我发现我自己有选择地避免使用特定的命令，以避免踏雷，这极大地影响了我，使 +我不能按照我喜欢的方式工作。 -当我不得不运行一个慢的命令的时候，这种等待极大地破坏了我思绪连续性。在等待服 -务器通讯完成的时候，我选择做其他的事情以度过这段时光，比如查看邮件或写其他的 -文档。当我返回我原先的工作场景的时候，这个命令早已结束，并且我还需要浪费时间 -试图记起我之前正在做什么。人类不擅长场景间的切换。 +当我不得不运行一个速度缓慢的命令时，这种等待极大地破坏了我思绪的连续性。在等 +待服务器通讯完成的时候，我选择做其他的事情以度过这段时光，比如查看邮件或写其 +他的文档。当我返回我原先的工作场景的时候，这个命令早已结束，并且我还需要浪费 +时间试图记起我之前正在做什么。人类并不擅长场景间的切换。 还有一个有意思的大众悲剧效应：预料到网络拥挤，为了减少将来的等待时间，每个人 -将比以往消费更多的带宽在各种操作上。共同的努力加剧了拥挤，这等于是鼓励个人下 -次消费更多带宽以避免更长时间的等待。 - - +将比以往消费更多的带宽在各种操作上。大家共同的努力结果加剧了拥挤，这等于是鼓 +励个人下次消费更多带宽以避免更长的等待时间。 -- 2.11.4.GIT