8、Git 提交操作全解析

Git 提交操作全解析

1. 提交时机与原子性变更集

在开发过程中，当处于相对稳定的阶段，比如测试套件通过、一天工作结束大家下班等时候，就适合进行提交操作。不过，不要犹豫频繁提交，Git 非常适合频繁提交，并且提供了丰富的命令来管理这些提交。

每个 Git 提交都代表着相对于前一个状态的一个原子性变更集。无论一个提交中更改了多少个目录、文件、行或字节，要么所有更改都应用，要么都不应用。从底层对象模型来看，原子性是合理的，因为一个提交快照代表了修改后的文件和目录的完整集合。它必须代表一种树状状态，两个状态快照之间的变更集代表了完整的树到树的转换。

举个例子，将一个函数从一个文件移动到另一个文件，如果分两次提交，先删除再添加，那么在仓库历史中会存在一个“语义间隙”，在这个间隙期间函数是缺失的。反之，先添加再删除也会有问题。但如果使用一个原子提交，同时完成删除和添加操作，历史记录中就不会出现这种语义间隙。

Git 并不关心文件为什么改变，它只关注变更本身。这意味着作为开发者，你可以将函数的移动操作视为一个整体，也可以分开提交删除和添加操作。而 Git 实现原子性的一个关键原因是，它允许你根据最佳实践建议更合理地组织提交。

2. 识别提交

无论是个人开发还是团队协作，识别单个提交都是一项重要任务。例如，创建分支时需要选择一个起始提交；比较代码差异时需要指定两个提交；编辑提交历史时需要提供一系列提交。在 Git 中，可以通过显式或隐式引用指向每个提交。

显式引用如唯一的 40 位十六进制 SHA1 提交 ID，而隐式引用如 HEAD，它始终指向当前分支的最新提交。不过，有时这两种引用都不太方便，好在 Git