Git提交信息的推荐格式

Question

Git提交信息的推荐格式

gitversion-controlformattingconventions

12

如果有的话，Git提交消息的推荐格式是什么？

- lucas clemente

3个回答

2

我不建议发送大的消息。如果你无法用一句话解释你正在做什么，那么你的提交包含的变化太多了。使用git rebase -i将你的提交拆分成多个部分。如果你还没有提交这些更改，请使用git add -p逐个提交小部分，然后作为较小的提交进行提交。

这样的细粒度更改历史将有助于后续的合并和重置。它还将帮助你链接到你的问题跟踪器。如果你处理了2个或更多的票据，那么很难确定每个提交中的变化是针对哪个票据的。

- Adam Dymitruk

2

非微不足道的更改通常需要大量的解释，特别是如果你正在处理一个需要保留外部和/或内部规范文档语义的大型项目。我曾经不得不写四段落的提交消息来更改MPICH源代码中的单个宏，因为我必须解释MPI标准行为和内部宏语义以证明更改的合理性。如果我没有这样做，一些未来的开发人员将浪费大量时间重新发现这些信息。如果可以的话，我会给它点踩... - Jeff Hammond

谢谢，@Jeff。软件是一个如此巨大的世界，它真的不是关于规则，而是关于指导方针。有时候，无法应用它们。 - Adam Dymitruk

我同意原子提交的想法（这就是为什么我通常不喜欢压缩），但我觉得最好错误地提供比所需更多的上下文。此外，如果工作没有作为原子提交提交，我不建议像你建议的那样将它们拆分。这会增加提交不完整代码的风险。 - Justin Ohms

0

提交的差异描述了项目中的一个文本变化（语法变化），而提交的消息则描述了项目中的一个含义变化（语义变化）。

提交消息格式：

第一行描述了语义上的变化及其范围。它仅限于50个字符，使用祈使语气书写，并不以句号结尾。
下一行留空。
其余行描述了语义变化之前和之后以及其限制的语义上下文。它们被包裹在72个字符内。

提交消息示例：

Percent-encode requests_mock URIs in API tests

Before, 32 API tests failed with the default .env file because it 
contains the characters ‘<’ and ‘>’ (used as variable delimiters) which 
are automatically percent-encoded in requests URIs (as those characters 
are not allowed in URIs) but not in requests_mock URIs.

Now, all tests pass with the default .env file.

This does not percent-encode URIs in non-failing tests.

Add a company selection page in HTML templates

Before, users logged in to different accounts by entering different 
credentials in the login page.

Now, users log in to different accounts by entering the same credentials 
in the login page and selecting different companies in the company 
selection page.

This does not allow logged in users to switch account without logging 
out.

参考资料:

- Géry Ogam

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jakob Borg · Accepted Answer

当然，它会有所不同，但一个非常常见的格式看起来是这样的（摘自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

有一件事情它没有提及到，那就是我自己采用的方法，即在第一行使用短标记来标识提交的类型。这些标记可能是 [fix] 表示修复bug，[new] 表示新功能，或者[dev] 仅影响内部的提交。采用这样的策略，可以轻松地从提交生成更改日志。

编辑： 这里还有另一个很好的总结，甚至来自于这个网站：在Git中，有哪些好的规范可用于格式化多个注释以单个提交