使用 git commit 保存项目快照是基本的。然而,仅仅保存更改是不够的。每次提交都需要一条信息,这些信息的质量显著影响项目历史记录的有用性。可以将提交信息视为项目演变过程的记录。清晰、有用的信息能让你(以及你的协作者,如果有的话)更容易理解某项更改在几个月甚至几年后为何出现。好的提交信息对于以下方面很重要:理解历史记录: 当你使用 git log 时,有描述性的信息能快速告诉你每次提交完成了什么。调试: 如果引入了错误,写得好的提交信息可以帮助找出导致问题的提交。协作: 它们让团队成员无需详细分析代码就能理解更改的背景和目的。代码审查: 清晰的信息为审查者提供背景信息,使审查过程更高效。好的提交信息的结构Git 提交信息的普遍接受约定遵循特定结构:主题行: 简短、概括性的更改摘要(理想情况下少于50个字符)。空行: 一条空行,将主题与正文分隔开。正文(可选但推荐): 对更改进行更详细的解释,说明“是什么”和“为什么”。我们来分解每个部分。主题行:保持简短和祈使句式主题行是提交信息中最重要的部分。当你运行 git log --oneline 等命令时,你看到的就是它。使用祈使句式: 编写主题行时,就好像在下达命令或指示。例如,使用“Fix login bug”(修复登录错误)而不是“Fixed login bug”(已修复登录错误)或“Fixes login bug”(修复登录错误)。此约定与 Git 自身生成的命令(如 git merge 或 git revert)相符。可以将其理解为描述此提交应用后所做的事情。首字母大写: 就像句子的开头一样。保持简明: 目标是少于50个字符。这确保它在各种 Git 工具中显示良好,不会被截断。末尾不加句号: 主题行就像标题;它们通常末尾不加句号。示例:好的: Add user authentication endpoint好的: Refactor database connection logic好的: Correct typo in README.md不太好: fixed stuff(太模糊)不太好: Implemented new feature for users to log in and out.(太长,不是祈使句式)不太好: fixing the css alignment issue on the main page(未大写,不是祈使句式)正文:解释是什么和为什么虽然主题行提供了快速摘要,但正文是你可以详细阐述的地方。它与主题行之间通过一条空行分隔。这种分隔很重要,因为许多 Git 工具将第一行视为主题,空行后的所有内容视为正文。解释动机: 为什么这项更改是必要的?它解决了什么问题?提供可能无法从代码本身看出来的背景信息。描述方法: 简要说明更改如何解决了问题,尤其当它涉及不明显的决策或权衡时。折行: 正文中的行应保持在72个字符左右折行。这可以提高在终端和 git log 等工具中的可读性。大多数文本编辑器都可以配置为自动执行此操作。引用问题(如果适用): 如果你的项目使用问题追踪器(如 GitHub Issues 或 Jira),引用相关问题编号(例如,Fixes #42,Addresses ticket T-123)。有些平台会根据这些引用自动将提交链接到问题。你不总是需要正文。对于非常简单的更改(如修复拼写错误),清晰的主题行可能就足够了。然而,对于任何更复杂的内容,强烈推荐提供详细的正文。完整示例这是一个结构良好的提交信息示例:用50个字符左右或更少字符概述更改 更详细的解释性文本,如果需要。将其折叠到大约72个字符左右。 在某些情况下,第一行被视为提交的主题,其余文本被视为正文。 将摘要与正文分隔开的空行很重要(除非你完全省略正文); 如果将两者放在一起,`log`、`shortlog` 和 `rebase` 等各种工具可能会混淆。 解释此提交正在解决的问题。着重说明你为什么要进行此更改, 而不是如何进行(代码会解释这一点)。 此更改是否有副作用或其他不直观的后果?这里是解释它们的地方。 更多段落出现在空行之后。 - 也可以使用项目符号 - 通常,项目符号使用连字符或星号,前面有一个空格, 之间有空行,但约定在这里有所不同。 如果你使用问题追踪器,请在底部放置对它们的引用,像这样: 解决:#123 另见:#456, #789提交信息结构示例,基于社区最佳实践。它为何重要花额外的几分钟精心编写一条好的提交信息,从长远来看回报显著。它能将你的 Git 历史记录从简单的更改日志转变为理解项目发展的宝贵资源。当你需要弄清楚某段代码为何存在,或者追查回归时,清晰的提交信息可以为你节省数小时的挫败感。当你开始与他人协作时,一致且有用的提交信息对于高效的团队协作变得更加重要。现在就开始养成这个习惯,即使是对于你的个人项目;未来的你会感谢你。