写git提交信息时应遵循的标准

Question

我发现我管理了很多文件（超过60个但不到70个），并且我的提交信息到目前为止遵循以下模式： 当我添加类似于 layout.css 这样的东西时，我的提交信息是 "added something on layout.css file"，当我删除一些东西时，我的提交信息是 "removed something from layout.css file"。

到后面有些文件，我看着我的提交记录，added... 和 removed... 的信息占据主导地位。有时我不记得我删除或添加了什么在 layout.css 中，因为我一次会做很多修改，所以我难以想出一个恰当的提交信息。

是否有一个标准可以帮助我编写提交信息？

- Gandalf

---

https://dev59.com/03E95IYBdhLWcg3wft5w - vijay

这个问题不是与链接中的问题重复。这个问题询问提交信息的内容，而链接的问题询问特定的格式化做法。 - Ajedi32

参见：http://www.commitlogsfromlastnight.com/ 和 https://whatthecommit.com/ ... 当然还有 https://www.reddit.com/r/ProgrammerHumor/comments/375fjr/whats_the_most_humorous_commit_message_youve_ever/ ；-) - Martin Thoma

Answer 1

当你只是用模糊的技术术语描述你的工作时（如“添加了一个函数”），你并没有给Git已经存储在提交中的内容增加多少。想象一下，过一段时间后你自己再读一下这个提交的消息，什么样的摘要会最有助于你记住或向其他开发人员传达该变更的精髓?！具体内容取决于项目和流程，但我发现这是一个很好的指导方针。

因此，首先在提交消息中添加上下文（即“为什么”，而非“如何”）（例如，“使用frobnize处理消息以实现持久性”而不是“添加frob()函数”）。这需要更多的努力（你必须反思和思考），但它所产生的价值远远超过付出的代价。

如果你想探索更多关于这个主题的信息，可以查阅大量的资料，例如Peter Hutterer的博客文章或者这个滑稽的幻灯片。

- Ingo Karkat

---

强调“为什么”而不是“怎么做”，给它点赞（+1）。 - Gady

@Bernard：这只是一个占位符的虚假无意义动词。它源自于《黑客用语词典》中的“frob”和“frobnicate”。 - Ingo Karkat

• 为了这个有趣的幻灯片，请加上“+”。

- extempl

Answer 2

50/72模式似乎是一种很好的做法。即...第一行应该最多为50个字符，并且应该作为标题。其后跟着一个空格，第二组行应该在72个字符处换行，并作为摘要。 以下是一个SO问题：Git Commit Messages：50/72 Formatting，讨论了同样的问题。

以下是有关此主题的详尽说明：

1. GIT提交良好实践
2. 关于Git提交消息的说明
3. 正确的Git提交消息和优雅的Git历史记录

- vijay

Answer 3

Git已经知道你在提交中修改了哪些文件，因此在注释中指定这些文件是无用的。只需说例如“修复填充错误”或“在侧边栏中添加菜单”。让它清晰明了，就这样。

- mimipc

---

根本原因也很重要：“填充使边缘包裹菜单栏”或“菜单栏在侧边栏中比在标题栏中更合适（UX规则42）”。 - Xenos

实际上，在 Git 中，你应该使用一个让人清楚了解补丁被应用到代码库后会_做什么_的信息作为提交信息，而不是描述_已完成_的事情（在其他版本控制系统中更常见）。因此，“修复填充错误”和“在侧边栏中添加菜单”会更加常规。请参阅在主题行中使用祈使语气（还请参阅主题行大写）。 - friederbluemle