《使用 Git 进行版本控制》第三版

第 16 章 高级操作 高级操作

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

本章将讨论一些操作 Git 仓库的高级命令。这些命令包括从操作文件到搜索提交，甚至支持分析和修改仓库以满足特定需求。正如你已经知道的，操作 Git 仓库确实会带来一些后果，特别是在执行改变仓库的 Git 提交历史的操作时。执行此类命令时，请务必小心谨慎。

互动大块头分期

这是一个有点不吉利的名称； 不过，交互式大块分期是一个非常强大的工具，用于简化和组织开发，使其成为简洁易懂的提交。如果有人要求你拆分补丁或制作单一概念的补丁，本节很可能就是为你准备的！

除非你是一个超级编码员，你的思维和开发都很简洁，否则你的日常开发过程很可能与其他开发人员（包括我们）的开发过程相似：有点零散，可能过度扩展，而且很可能包含几个相互交织的想法。一个编码想法引发另一个编码想法，很快您就修复了最初的错误，又偶然发现了另一个错误（但还是修复了！），然后在修复的同时又添加了一个简单的新功能。哦，你还修正了两个错别字。

而且，如果你和我们一样，希望在要求上游接受你对重要代码所做的修改之前，有人对你的修改进行审核，那么很可能所有这些不同的、互不相关的修改都不会使一个补丁的呈现合乎逻辑。事实上，有些开源项目坚持要求提交的补丁包含独立的修正。也就是说，一个补丁不应该同时实现多个目的。相反，每个想法都应独立存在，并应作为一个定义明确的、简单的补丁来展示，补丁的大小应足以完成工作，仅此而已。如果需要向上游传输的想法不止一个，那么就需要不止一个补丁，也许是一个序列。常识告诉我们，这类补丁和补丁序列会带来非常可靠的审核、快速的周转，并很容易被上游主线开发所接受。

那么，这些完美的补丁序列是如何产生的呢？虽然我们一直在努力创造一种便于打补丁的开发风格，但并不总是成功。尽管如此，Git 还是提供了一些工具来帮助打好补丁。其中一个工具能让我们交互式地选择并提交补丁的片段，或称 "大块"，而将其余部分留在后面的补丁中提交。最终，你会希望创建一个由更小的提交组成的新序列，而这些提交仍然是你最初工作的总和。

Git 不能帮你决定补丁中哪些概念片段属于一起，哪些不属于。你必须有能力辨别意义，并将逻辑上合理的片段组合在一起。有时，这些片段都在一个文件中，但有时却在多个文件中。总的来说，所有概念上相关的补丁都必须被选中，并作为一个提交的一部分一起提交。

此外，您还必须确保所选择的块仍能满足任何外部要求。例如，如果您正在编写必须编译的源代码，您很可能希望确保代码库在每次提交后都能继续编译。因此，你必须确保你的补丁分割成更小的部分后，在每次提交时仍能在新的序列中编译。Git 无法帮你做到这一点，这就需要你去思考了。

只需在git add 命令中添加-p 选项，就能轻松实现交互式暂存！

    $ git add -p file.c
    

交互式大块暂存看起来很简单，事实也的确如此。但我们还是应该对 Git 处理我们的补丁有一个心理模型。记得在第 5 章中，我们解释过 Git 是如何将索引作为一个暂存区，在提交之前累积你的修改。现在依然如此。但现在 Git 不再是一次收集整个文件的改动，而是将你在文件工作拷贝中所做的改动分门别类，并允许你选择将哪一部分或哪几部分放到索引中，等待提交。

假设我们正在开发一个程序，用来打印文件中以空白分隔的单词直方图。这个程序的第一个版本就是 "Hello, World!"程序，它证明了编译工作已经步入正轨。下面是main.c：

 #include ...