编写 git commit 消息时要遵循的标准
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/15324900/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Standard to follow when writing git commit messages
提问by Gandalf
I find myself managing very many files (over 60 but below 70) and my commit messages so far follow this pattern:
when I have added something like on layout.css, my commit message is "added something on layout.css file", and when I remove something, my commit message is "removed something from layout.css file".
我发现自己管理了很多文件（超过 60 个但低于 70 个），到目前为止我的提交消息遵循这种模式：当我添加了类似 on 的东西时layout.css，我的提交消息是“在 layout.css 文件上添加了一些东西”，当我删除一些东西，我的提交消息是“从 layout.css 文件中删除了一些东西”。
Some files down the line, I look at my commits feed and added...and removed...messages dominate. Sometimes I don't remember what I removed or what I added in layout.csssince I make so many changes at a go and so I struggle to come up with an appropriate commit message.
一些文件，我查看了我的提交提要并添加...和 删除...消息占主导地位。有时我不记得我删除了什么或添加了什么，layout.css因为我一次做了很多更改，所以我很难想出合适的提交消息。
Is there a standard I should follow to help me come up with my commit messages?
是否有我应该遵循的标准来帮助我提出我的提交消息？
回答by Ingo Karkat
When you just describe what you've done (in technical yet fuzzy terms like "added a function"), you're not adding much to what Git already stores in the commit. Imagine yourself reading the commit message some time later; what kind of summary would help you most remembering / communicating to other developers the essence of that change?! The exact contents depend on your project and processes, but I find that a good guideline.
当你只描述你所做的事情（用技术性但模糊的术语，比如“添加一个函数”）时，你并没有为 Git 已经存储在提交中的内容添加太多内容。想象一下你在一段时间后阅读提交信息；什么样的摘要最能帮助您记住/与其他开发人员交流该更改的本质？！确切的内容取决于您的项目和流程，但我发现这是一个很好的指南。
Therefore, first and foremost add context (the why, not the how) with your commit message (e.g. "frobnize the message to enable persistence") instead of "added frob() function"). It's more effort (you have to reflect and think), but it is worth so much more.
因此，首先要在提交消息中添加上下文（为什么，而不是如何）（例如“冻结消息以启用持久性”），而不是“添加 frob() 函数”）。这是更多的努力（你必须反思和思考），但它更值得。
If you want to explore more about this topic, there's a wealth of information, for example this blog article by Peter Huttereror this funny slide.
如果您想进一步了解这个主题，这里有大量信息，例如Peter Hutterer 的这篇博客文章或这张有趣的幻灯片。
回答by vijay
The 50/72 model seems to be a good practice. i.e. ... the first line should be maximum 50 chars long and should server as a header. Followed by a space, the second set of line(s) should be wrapped at 72 chars and should serve as a summary. Here is a SO question : Git Commit Messages : 50/72 Formatting, that discusses the same.
50/72 模型似乎是一个很好的做法。即...第一行最多应为 50 个字符长，并应作为标题服务器。后跟一个空格，第二组行应该用 72 个字符换行并作为摘要。这是一个 SO 问题：Git Commit Messages : 50/72 Formatting，讨论相同。
Here are some exhaustive notes on the subject:
以下是有关该主题的一些详尽说明：
回答by mimipc
Git already knows which files you modified in a commit, it's useless to specify it in the comment. Just say for example "fixed padding bug" or "added menu in sidebar". Make it clear, that's it.
Git 已经知道你在提交中修改了哪些文件，在注释中指定它是没有用的。只需说例如“修复了填充错误”或“在侧边栏中添加了菜单”。说清楚，就是这样。
