我使用 git 已经有一段时间了，我有一个问题。为什么在使用git commit时需要添加提交信息？我的意思是，我承认在某些情况下，当我真正想解释特定更改对项目有什么影响时，它对我非常有用。
但为什么仍然有必要编写提交消息？我的意思是，如果我在我的 UI 中进行一些小改动，比如修复拼写错误，该怎么办？有必要这样做是件好事吗？还是如果这是可选的会更好/最差？
【问题讨论】：
git commit --allow-empty-message 允许空消息。因此，您可以在没有消息的情况下创建提交，只要您认为没问题并且不会给您或其他人带来任何困惑或麻烦。
标签： git version-control git-commit
如果它是可选的，用户可以选择忽略它，即使他们确实应该解释发生了什么变化。
如果它不是可选的，那么用户在最坏的情况下会因为不得不编造诸如“修复错字”之类的琐碎提交消息而感到不便。
理想情况下，您应该能够查看git log --oneline 的输出，并且仍然了解所做的更改。考虑这个日志：
a2b2c3 Fix another critical error in bar
abcdef
123456 Introduce critical method bar
您想假设abcdef 是一个小错字，有人认为不值得评论，还是假设它是在下一次提交中使用“另一个”暗示的重大错误修复？
严格来说，这不是必要的；这只是强制添加提交消息的默认设置。您可以使用git commit --allow-empty-message 继续没有一个。
【讨论】：
Git 默认需要提交消息，因为在软件开发中，实际上需要与其他人交流，而提交消息是传达有关提交的各种详细信息的最佳方式，包括它做了什么，为什么要更改是必要的，改变的好处和缺点，以及为什么这种改变比替代方案更好。沟通是工作场所和开源项目中的一项基本技能，编写提交也是如此。
有时，与您交流的另一个人就是未来的您。过去，我曾使用我的提交消息来记录更改的详细信息，我必须在两周后回忆并解释给同事。如果我没有把它们写在某个地方，我不会记得这些细节。
即使更改微不足道，您仍然想知道它的作用。当您查看git log 时，您会想知道这是否是 CSS 更改（这可能是您的 UI 错误的原因），或者是错字修复（可能不是）。无论如何，由于许多开发人员进行了大量的小更改，因此不为小更改指定提交消息意味着大量更改最终会没有提交消息，从而导致历史混乱。
在许多情况下，您可以通过使用git commit --fixup 将修复提交压缩到该系列中较早的提交中，然后使用git rebase -i --autosquash BASE 压缩它们来避免这些小错字修复和类似更改。这样你就不必输入提交信息，而且一开始没人会知道你打错了。
如果你真的想跳过它，你可以使用--allow-empty-message 参数到git commit。但是，如上所述，如果您与其他人一起工作，他们可能不会欣赏这种提交方式。
【讨论】：