Git提交消息：50/72格式化

蒂姆·波普（Tim Pope）在他的博客文章：http ://www.tpope.net/node/106中主张一种特定的Git commit消息样式 。

这是他的建议的快速摘要：

• 第一行不超过50个字符。
• 然后是空白行。
• 其余文字应以72个字符换行。

他的博客文章提供了这些建议的理由（为简便起见，我将其称为“ 50/72格式”）：

• 实际上，有些工具将第一行作为主题行，将第二段作为正文（类似于电子邮件）。
• git log 不处理换行，因此如果行太长则很难阅读。
• git format-patch --stdout 将提交内容转换为电子邮件-如果要很好地打包您的提交内容，发挥作用会很有帮助。

我想补充一点，我认为蒂姆会同意：

• 在任何版本控制系统中，总结提交的行为本质上是一种好的做法。它可以帮助其他人（或以后的您）更快地找到相关的提交。

因此，我对我的问题有两个角度：

• Git的“思想领袖”或“经验丰富的用户”中有多少（大致）接受50/72格式设置？我之所以这样问，是因为有时新用户不了解或不关心社区实践。
• 对于那些不使用这种格式的人，是否有原则上的理由使用其他格式样式？（请注意，我在寻找关于案情的论据，而不是“我从未听说过”或“我不在乎”。）
• 从经验上讲，有多少百分比的Git存储库采用这种风格？（以防某人想对GitHub存储库进行分析……提示，提示。）

我的意思不是推荐50/72风格或击落其他风格。（要公开，我确实喜欢它，但是我对其他想法持开放态度。）我只是想了解为什么人们喜欢或反对各种Git提交消息样式的理由。（也可以提出未提及的要点。）

关于“摘要”行（公式中的50），Linux内核文档中这样说：

For these reasons, the "summary" must be no more than 70-75
characters, and it must describe both what the patch changes, as well
as why the patch might be necessary.  It is challenging to be both
succinct and descriptive, but that is what a well-written summary
should do.

就是说，内核维护者确实确实试图将其保持在50附近。这是内核git日志中摘要行长度的直方图：

（查看大图）

有一些提交的摘要行比该图所能容纳的摘要行更长（有些更长），而不会使有趣的部分看起来像一条单独的行。（可能有一些花哨的统计技术可以将这些数据合并到这里，但是好吧……:-)

如果要查看原始长度：

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{print length($0)}'

或基于文本的直方图：

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{lens[length($0)]++;} END {for (len in lens) print len, lens[len] }' | sort -n

关于“思想领袖”：Linus强烈主张换行以表示完整的提交信息：

[…]我们使用72个字符的列进行换行，但带有特殊行格式的引用材料除外。

例外主要是指“非散文”文本，即不是由人类键入的文本，例如，编译器错误消息。

表示和数据的分离在这里驱动了我的提交消息。

您的提交消息不应以任何字符数进行硬包装，而应使用换行符将想法，段落等分隔为数据的一部分，而不是表示的一部分。在这种情况下，“数据”是您试图传达的消息，而“演示”是用户如何看待它。

我在顶部使用一个汇总行，并尽量使其简短，但我不限制自己为任意数。如果Git实际上提供了一种方法来将摘要消息存储为与消息分开的实体，那会好得多，但是由于不必这样做，因此我不必侵入其中，而是使用第一行换行符作为分隔符（幸运的是，许多工具都支持这意味着拆分数据）。

对于消息本身，换行符表示数据中有意义的内容。单个换行符指示列表中的开始/中断，而双换行符指示新的思想/想法。

This is a summary line, try to keep it short and end with a line break.
This is a thought, perhaps an explanation of what I have done in human readable format.  It may be complex and long consisting of several sentences that describe my work in essay format.  It is not up to me to decide now (at author time) how the user is going to consume this data.

Two line breaks separate these two thoughts.  The user may be reading this on a phone or a wide screen monitor.  Have you ever tried to read 72 character wrapped text on a device that only displays 60 characters across?  It is a truly painful experience.  Also, the opening sentence of this paragraph (assuming essay style format) should be an intro into the paragraph so if a tool chooses it may want to not auto-wrap and let you just see the start of each paragraph.  Again, it is up to the presentation tool not me (a random author at some point in history) to try to force my particular formatting down everyone else's throat.

Just as an example, here is a list of points:
* Point 1.
* Point 2.
* Point 3.

这是软包装文本的查看器中的外观。

这是一个摘要行，请尝试使其简短并以换行符结尾。

这是一个想法，也许是我以人类可读格式所做的解释。它可能很复杂，而且很长，由几个以论文格式描述我的作品的句子组成。我现在不能决定（在作者时）用户将如何使用此数据。

两个换行符将这两个想法分开。用户可能正在电话或宽屏监视器上阅读此内容。您是否曾经尝试在只能显示60个字符的设备上阅读72个字符的自动换行符？这是一次真正的痛苦经历。另外，该段落的开头句子（假设论文样式格式）应该是该段落的简介，因此，如果工具选择它，可能不希望自动换行，而只看到每个段落的开头。再次，由展示工具而不是我（在历史上某个时候是一位随机作者）来试图迫使我采用特定的格式来降低所有人的痛苦。

举例来说，这里是一个点列表：
*点1.
*点2.
*点3。

我的怀疑是，您链接的Git提交消息推荐的作者之前从未编写过供不同终端（例如，网站）使用不同设备的大量最终用户使用的软件，因为在这一点上软件/计算的发展众所周知，就用户体验而言，使用硬编码的演示信息存储数据是一个坏主意。

我同意提出一种特殊的工作风格很有趣。但是，除非有机会设置样式，否则我通常会遵循所做的工作以保持一致性。

看一下Linux Kernel Commits，这个启动了git的项目，http： //git.kernel.org/？p = linux / kernel / git / torvalds / linux-2.6.git; a = commit; h = bca476139d2ded86be146dae09b06e22548b67f3，他们没有遵循50/72规则。第一行是54个字符。

我会说一致性很重要。设置适当的方法来识别已提交的用户（user.name，user.email-尤其是在内部网络上。User@ OFFICE-1-PC-10293982811111不是有用的联系地址）。根据项目，在提交中提供适当的详细信息。很难说那应该是什么。它可能是在开发过程中完成的任务，然后是更改的详细信息。

我不认为用户应该以一种方式使用git，因为某些用于git的接口以某些方式来处理提交。

我还应该注意，还有其他查找提交的方法。首先，git diff将告诉您发生了什么变化。您也可以git log --pretty=format:'%T %cN %ce'进行格式化的选项git log。

建议的最大标题长度真的是50吗？

我已经相信了多年，但是正如我刚刚注意到的“ git commit”文档实际上指出的那样

$ git help commit | grep -C 1 50
      Though not required, it’s a good idea to begin the commit message with
      a single short (less than 50 character) line summarizing the change,
      followed by a blank line and then a more thorough description. The text

$  git version
git version 2.11.0

有人可能会说“少于50”只能表示“不超过49”。