Git提交消息:50/72格式

Tim Pope在他的博客文章中提出了一种特定的Git提交消息风格: http://www.tpope.net/node/106 . < / p >

以下是他的建议:

  • 第一行不超过50个字符。
  • 然后是空行。
  • 剩下的文本应该以72个字符换行。

他的博客文章给出了这些建议的基本原理(为了简洁起见，我将其称为“50/72格式”):

  • 在实践中，一些工具将第一行作为主题行，第二段作为主体(类似于电子邮件)。
  • git log不处理换行，所以如果行太长就很难读取。
  • git format-patch --stdout将提交转换为电子邮件-所以如果你的提交已经很好地包装了，它会有帮助。

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

  • 总结提交的行为在任何版本控制系统中都是一种固有的良好实践。它可以帮助其他人(或者后来的你)更快地找到相关的提交。

我有几个角度来回答我的问题:

  • Git的“思想领袖”或“有经验的用户”中有多少人(大致)采用了50/72格式?我问这个问题是因为有时新用户不知道或不关心社区实践。
  • 对于那些不使用这种格式的人，使用不同的格式风格是否有原则性的原因?(请注意，我在寻找一个是非曲实的论点，而不是“我从未听说过”或“我不在乎”。)
  • 从经验上讲，有多少百分比的Git存储库采用这种风格?(以防有人想对GitHub存储库做分析……提示，提示。)

我在这里的重点不是推荐50/72风格或否定其他风格。(坦率地说，我确实更喜欢它，但我也愿意接受其他想法。)我只是想了解人们喜欢或反对各种Git提交消息风格的基本原理。(你也可以提一些没有被提及的问题。)

130914 次浏览
小开

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

看看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的选项。

小开
最佳答案

关于“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日志中总结行长度的直方图:

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
小开

关于“思想领袖”:莱纳斯强调主张对完整的提交消息进行换行:

[…]我们使用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点。< / p >

我怀疑你链接的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岁”。


提交答案