编写 git 提交消息时要遵循的标准 [重复]

Posted 2023-02-21

【中文标题】编写 git 提交消息时要遵循的标准 [重复]

【英文标题】：Standard to follow when writing git commit messages [duplicate]

【发布时间】：2013-02-25 19:43:18

【问题描述】：

我发现自己管理着非常多的文件（超过 60 个但低于 70 个）并且我的提交消息到目前为止都遵循以下模式： 当我在layout.css 上添加类似内容时，我的提交消息是“在 layout.css 文件中添加了一些内容”，当我删除某些内容时，我的提交消息是 “从布局中删除了一些内容.css 文件”.

一些文件，我查看我的提交提要，added... 和 removed... 消息占主导地位。有时我不记得我在layout.css 中删除了什么或添加了什么，因为我一次做了很多更改，所以我很难想出一个合适的提交信息。

是否有我应该遵循的标准来帮助我提出我的提交信息？

【问题讨论】：

***.com/questions/2290016/…

此问题与所链接的问题不重复。此问题询问提交消息内容，而链接问题询问特定格式设置。

另见：commitlogsfromlastnight.com 和 whatthecommit.com ...当然还有reddit.com/r/ProgrammerHumor/comments/375fjr/… ;-)

【参考方案1】：

当您只是描述您所做的事情时（用“添加了一个功能”之类的技术但模糊的术语），您并没有对 Git 已经存储在提交中的内容添加太多内容。想象一下自己在一段时间后阅读提交消息；什么样的总结最能帮助您记住/与其他开发人员交流该更改的本质？！具体内容取决于您的项目和流程，但我认为这是一个很好的指导方针。

因此，首先在您的提交消息中添加上下文（为什么，而不是如何）（例如“冻结消息以启用持久性”）而不是“添加了 frob() 函数”)。这是更多的努力（你必须反思和思考），但它值得更多。

如果您想进一步了解该主题，这里有大量信息，例如this blog article by Peter Hutterer 或this funny slide。

【讨论】：

+1 用于强调 why 而不是 how。

@Bernard：这只是一个假的无意义动词，作为一个占位符。来自Jargon file的“frob”和“frobncate”的起源。

+ for this funny slide

【参考方案2】：

50/72 模型似乎是一个很好的做法。即 ... 第一行的最大长度应为 50 个字符，并且应作为标题服务。后跟一个空格，第二组行应以 72 个字符换行并用作摘要。这是一个 SO 问题：Git Commit Messages : 50/72 Formatting，讨论了同样的问题。

以下是有关该主题的一些详尽说明：

GIT Commit Good Practice A Note About Git Commit Messages Proper Git Commit Messages and an Elegant Git History

【参考方案3】：

Git 已经知道你在提交中修改了哪些文件，在评论中指定它是没有用的。只需说例如“修复填充错误”或“在侧边栏中添加菜单”。说清楚，就是这样。

【讨论】：

根本原因也很好：“填充使边缘包裹菜单栏”或“菜单栏更适合侧边栏而不是标题栏（UX 规则 42）”

实际上，在 Git 中，您应该使用一条消息来明确补丁 在应用到存储库时会做什么 - 不是 是完成（在其他 vcs 中更常见）。因此Fix padding bug 和Add menu in sidebar 会更传统。见Use the imperative mood in the subject line（另见Capitalize the subject line）