为什么需要输入提交信息？
Why is it necessary to enter commit messages?
我使用 git 有一段时间了，我有一个问题。为什么在使用 git commit 时需要添加提交消息？我的意思是，我承认在某些情况下，当我真正想解释特定更改对项目的影响时，它对我非常有用。
但为什么仍然需要写提交信息？我的意思是，如果我要进行一些小改动，比如修复 UI 中的拼写错误怎么办？有必要这样做是件好事吗？或者如果这是可选的，它会是 better/worst 吗？
如果它是可选的，那么用户可以选择忽略它，即使他们确实应该解释发生了什么变化。
如果它不是可选的，最坏的情况下用户会因为不得不编写诸如“修正错字”之类的琐碎的提交消息而感到轻微的不便。
理想情况下，您应该能够查看 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。但是，如上所述，如果您与其他人一起工作，他们可能不会欣赏这种提交方式。
Git 2.36（2022 年第 2 季度）更新 contributor-facing 有关建议日志消息的文档。
它说明了为什么提交消息是 mandatory/important。
参见commit cdba029, commit 607817a, commit fa1101a (27 Jan 2022) by Junio C Hamano (gitster)。
（由 Junio C Hamano -- gitster -- in commit 8376093 合并，2022 年 2 月 11 日）
SubmittingPatches: explain why we care about log messages
Extend the "describe your changes well" section to cover whom we are trying to help by doing so in the first place.
SubmittingPatches 现在包含在其 man page 中：
The log message that explains your changes is just as important as the
changes themselves.
Your code may be clearly written with in-code
comment to sufficiently explain how it works with the surrounding
code, but those who need to fix or enhance your code in the future
will need to know why your code does what it does, for a few
reasons:
Your code may be doing something differently from what you wanted it
to do.
Writing down what you actually wanted to achieve will help
them fix your code and make it do what it should have been doing
(also, you often discover your own bugs yourself, while writing the
log message to summarize the thought behind it).
Your code may be doing things that were only necessary for your
immediate needs (e.g. "do X to directories" without implementing or
even designing what is to be done on files).
Writing down why you
excluded what the code does not do will help guide future developers.
Writing down "we do X to directories, because directories have
characteristic Y" would help them infer "oh, files also have the same
characteristic Y, so perhaps doing X to them would also make sense?".
Saying "we don't do the same X to files, because ..." will help them
decide if the reasoning is sound (in which case they do not waste
time extending your code to cover files), or reason differently (in
which case, they can explain why they extend your code to cover
files, too).
The goal of your log message is to convey the why behind your
change to help future developers.
我使用 git 有一段时间了，我有一个问题。为什么在使用 git commit 时需要添加提交消息？我的意思是，我承认在某些情况下，当我真正想解释特定更改对项目的影响时，它对我非常有用。
但为什么仍然需要写提交信息？我的意思是，如果我要进行一些小改动，比如修复 UI 中的拼写错误怎么办？有必要这样做是件好事吗？或者如果这是可选的，它会是 better/worst 吗？
如果它是可选的，那么用户可以选择忽略它，即使他们确实应该解释发生了什么变化。
如果它不是可选的，最坏的情况下用户会因为不得不编写诸如“修正错字”之类的琐碎的提交消息而感到轻微的不便。
理想情况下，您应该能够查看 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。但是，如上所述，如果您与其他人一起工作，他们可能不会欣赏这种提交方式。
Git 2.36（2022 年第 2 季度）更新 contributor-facing 有关建议日志消息的文档。
它说明了为什么提交消息是 mandatory/important。
参见commit cdba029, commit 607817a, commit fa1101a (27 Jan 2022) by Junio C Hamano (gitster)。
（由 Junio C Hamano -- gitster -- in commit 8376093 合并，2022 年 2 月 11 日）
SubmittingPatches: explain why we care about log messages
Extend the "describe your changes well" section to cover whom we are trying to help by doing so in the first place.
SubmittingPatches 现在包含在其 man page 中：
The log message that explains your changes is just as important as the changes themselves.
Your code may be clearly written with in-code comment to sufficiently explain how it works with the surrounding code, but those who need to fix or enhance your code in the future will need to know why your code does what it does, for a few reasons:
Your code may be doing something differently from what you wanted it to do.
Writing down what you actually wanted to achieve will help them fix your code and make it do what it should have been doing (also, you often discover your own bugs yourself, while writing the log message to summarize the thought behind it).Your code may be doing things that were only necessary for your immediate needs (e.g. "do X to directories" without implementing or even designing what is to be done on files).
Writing down why you excluded what the code does not do will help guide future developers. Writing down "we do X to directories, because directories have characteristic Y" would help them infer "oh, files also have the same characteristic Y, so perhaps doing X to them would also make sense?".Saying "we don't do the same X to files, because ..." will help them decide if the reasoning is sound (in which case they do not waste time extending your code to cover files), or reason differently (in which case, they can explain why they extend your code to cover files, too).
The goal of your log message is to convey the why behind your change to help future developers.