在提交时使用Git amend，而不是创建多个提交

根据我的理解，

git commit--amend

可以用来修改未完成的提交，以达到可理解的状态，修复拼写错误等。但是，有时它可能（错误地？）被用作保持提交历史记录更清晰的银弹（类似于压缩合并）

一位工程师只是假设，当在本地（分支上）开发一个复杂的特性时，他们在一个相同的提交上反复使用

git commit--amend

，直到特性完成为止。例如：

• 第一次提交：创建函数A和B的存根
• 第一次提交时第一次修改：功能A已实施
• 第一次提交第二次修改：功能B已实施
• 第一次提交时第三次修改：添加服务X

这样做的原因是他们试图保持提交历史记录的干净性，并尽可能减少提交）

这种以修改为中心的方法对我来说是新的，因为我通常试图通过为每个逻辑完成的状态添加一个提交来保持开发过程更透明。例如：

• 第一次提交：创建函数A和B的存根
• 第二次提交：实现功能A
• 第三次提交：实现功能B
• 第四次提交：添加服务X

据我所知，有多个提交可能有助于审查过程，有助于理解更改的单行（甚至是几年后），并有可能在开发过程中重置为较旧的中间状态（例如，在开发过程中出现死胡同的情况下），因为它不会被更改一次又一次地“覆盖”

此外，由于上游通常禁用了

git push--force

，

--amend

在提交被推送后将不再工作。在团队中工作时，它很可能也会导致问题

---

您认为使用“修正”来保持历史记录的干净是一种有效的方法，还是可以将其视为给定示例的反模式？可以将挤压合并理解为更准确的干净历史记录的方法。

考虑这种情况

您将一些代码重构为函数名

dothishing

，用对

dothishing

的调用替换3个基本相同的代码块，然后提交更改

测试时，您注意到其中一个调用拼写错误

dotshithing

，因此您更正了拼写错误

您是否真的认为将

dotshithing

更改为

dotshithing

值得单独提交，而不仅仅是在步骤1中修改提交以更正拼写

如果您共享提交，查看该提交的任何人都不可能也不需要知道您最初是否拼错了函数名。单独的第二次提交不会向查看提交历史的任何人传达任何有用的信息。

git commit--amend真正做的是非常简单的。它实际上不会更改任何提交，也不会更改任何使用it仍在进行多次提交。不幸的是，要真正理解这一点有点复杂。不过，你要问的是一个完全不同的问题：什么时候这是一个好主意，什么时候不是一个好主意

你想问的问题没有一个明确的答案：这是一个观点问题，因此不是关于StackOverflow的话题。除此之外，这是一个更大问题的一部分，这个问题甚至更模糊：一次提交中工作的适当粒度是什么

我们也确实无法回答这个问题，但我们可以采取技术方法来回答辅助问题，这些问题将反馈到最终的基于意见的答案中。具体来说，我们可以查看每个提交是什么，以及为我们做了什么。这使我们有点特定于Git，尽管其他版本控制系统中的提交通常是至少在效果方面非常相似（即使基础机制非常不同）：

• 提交表示组成系统的所有文件的快照

• 提交包含一些元数据：谁做了这件事，什么时候，也许最重要的是为什么。为什么部分以提交消息的形式出现

• 在Git中，历史记录是提交。Git通过将自己特定于Git的元数据以及用户提供的为什么存在此提交消息推入提交中来实现这一点

• 使用存储库中提交的历史记录，在Git的情况下，我们可以让我们的计算机自动完成几件事情。这里我要特别指出的两件事是：
  • 生成日志（无论出于什么目的：只是为了阅读以提醒我们自己，或者为发行说明构建更改日志，或者其他任何目的）

  • 自动化测试并进行二等分以查找bug

以上不一定是一个完整的列表，但我认为这是一个很好的起点

请注意，在某种程度上，最后两个要点的观点是相反的：生成日志的那一点主张更少的提交，因此日志更易于阅读和消化，从而提供更好的高层概述。同时，二分法思想主张提交尽可能小和细粒度，因此当我们引入bug，首先创建bug的单个提交足够小，当我们阅读差异时，问题会很明显。因此，我们应该尽可能少地提交，同时尽可能多地提交。1

如何解决这一问题是一个意见问题。然而，我们可以注意到，最小的合理提交是一个独立的提交：软件在提交之前工作，而软件在提交之后仍然工作。如果一组较大的更改（例如，添加一些功能）可以分解为两个或更多较小的更改，我们可以（根据意见）更倾向于“更细粒度”模式，我们应该打破这种模式