git的提交消息（COMMIT_EDITMSG）中使用的推荐格式是什么？如果有的话？
答案 0 :(得分：13)
当然，它有所不同，但是一种非常常见的格式是这样的（取自http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html，我认为总结得很好）：
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
我没有解决的一件事是我自己采用的东西，即在firstt行的开头使用短标签来识别它是什么类型的提交。对于错误修正，这可能是[fix]，对于新功能可能是[new]，对于仅影响内部的提交，可能是[dev]。使用这样的策略，可以很容易地从提交中自动生成更改日志。
修改：这是另一个很好的摘要，甚至来自这个网站：In git, what are some good conventions to format multiple comments to a single commit
答案 1 :(得分：1)
我不推荐大邮件。如果你不能用一句话解释你在做什么，你的提交包含太多的改变。如果已提交，请使用git rebase -i并拆分提交。如果您还没有提交更改，请使用git add -p进行小部分暂存，然后提交为较小的提交。
像这样的粒度更改历史记录将有助于后续合并和重组。它还可以帮助您链接到问题跟踪器。如果您有2张或更多的故障单，那么在解决提交中的每个更改的解码将更加困难。