何时进行 Git 提交

AWS 安全直播！

你不需要查看太多 GitHub 上的提交历史记录就能发现，人们在提交代码方面做得非常糟糕。

现在我不打算讨论如何编写提交信息，相关内容请参阅这篇文章。我想谈谈另一个同样重要的话题：何时进行提交。

我在会议上经常被问到这个问题。以至于我总结了两条规则，并不断进行检验。

我会在以下情况下提交：

只要满足这些规则中的任何一条，我就提交这组更改。需要明确的是，我只提交这组更改。例如，如果我有一些可能需要撤销的更改，以及一些完成某个工作单元的更改，我会进行两次提交——一次包含可能需要撤销的更改，另一次包含完成该工作单元的更改。

我认为第二条规则非常简单明了，所以我们先来看它。随着时间的推移，你会做出一些你知道最终会被撤销的更改。无论是促销功能、补丁还是其他临时性更改，总有一天你会想要撤销这些工作。

如果真是这样，我会把这些更改单独提交一次。这样更容易找到并使用这些更改git revert。这种做法已经反复证明是行之有效的，即使是我自己不太确定的更改，我也会单独提交一次。

所以，让我们回到第一条规则。

我认为我们大多数人通常都会遵守这条规则。然而，你只要在 GitHub 上浏览几个代码仓库就能发现，我们在提交记录方面做得非常糟糕。

这些差异源于我们对工作单元的定义。

让我们先来看看如何错误地定义工作单元。

工作单元绝对不是基于时间的。每隔几分钟、几小时或几天就提交一次代码是荒谬的，而且除了用于编年史系统之外，这种做法永远无法产生任何有价值的版本历史记录。

是的，WIP（进行中）提交是可以的。但如果它们出现在你的主分支历史记录中，我就要找你算账了！

工作单元并非基于变更类型。将新文件和已修改文件分开提交通常意义不大。其他任何类型抽象也同样如此：代码（例如 JavaScript 与 HTML）、层（例如客户端与 API）或位置（例如文件系统）。

如果一个工作单元不是基于时间或类型，那它又是什么呢？

我认为应该以功能为基础。功能能提供更多上下文信息，因此更适合作为工作单元的衡量标准。通常，上下文信息中隐含着时间、类型以及变更的性质等内容。换句话说，以功能为基础来定义工作单元，能引导你提交的内容更能讲述一个完整的故事。

那么，为什么不直接制定第一条规则：当我完成一个功能时，就提交一次代码呢？

我认为这是一个过程很重要的例子。即使在同一个代码库中，一个功能也可能意味着不同的东西。功能的大小也可能不同。使用工作单元（Unit of Work）可以让你灵活地控制单元的大小。你只需要知道如何衡量。我发现按功能来提交是最佳选择。

喜欢这篇文章吗？来看看我的Git 入门视频系列吧。