关于“summary”行(公式中的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

关于“summary”行(公式中的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

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

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

我在顶部使用单一的总结行，并尽量保持简短，但我不会限制自己的任意数字。如果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.

下面是它在软换行文本的查看器中的样子。

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.

我怀疑你链接的Git提交消息推荐的作者以前从未编写过将被不同设备上的大量终端用户使用的软件(即网站)，因为在软件/计算的发展过程中，众所周知，就用户体验而言，用硬编码的表示信息存储数据是一个坏主意。

推荐的最大标题长度真的是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岁”。

我同意提出一种特殊的工作风格是很有趣的。然而，除非我有机会设置风格，否则我通常会遵循已经完成的一致性。

看看Linux内核提交，这个启动git的项目http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bca476139d2ded86be146dae09b06e22548b67f3，他们不遵循50/72规则。第一行是54个字符。

我想说一致性很重要。设置正确的方法来识别已经提交的用户(user.name, user.name, user.name)。电子邮件——尤其是在内部网络上。User@OFFICE-1-PC-10293982811111不是一个有用的联系地址)。根据项目的不同，在提交中提供适当的细节。很难说这应该是什么;它可能是在开发过程中完成的任务，然后是更改的细节。

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

我还应该指出，还有其他查找提交的方法。首先，git diff会告诉你发生了什么变化。你也可以像git log——pretty=format:'%T %cN %ce'这样来格式化git log的选项。

关于“思想领袖”:Linus强调在提交信息中使用换行:

我们使用72个字符的列来换行，除了引号 具有特定行格式的材料。

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