Git提交消息:50/72格式化 [英] Git Commit Messages: 50/72 Formatting

问题描述

Tim Pope在他的博客文章中主张一种特定的Git commit消息样式: http://www.tpope.net/node/106 .

Tim Pope argues for a particular Git commit message style in his blog post: http://www.tpope.net/node/106.

以下是他推荐的内容的简短摘要:

Here is a quick summary of what he recommends:

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

他的博客文章提供了这些建议的理由(为简便起见，我将其称为"50/72格式"):

His blog post gives the rationale for these recommendations (which I will call "50/72 formatting" for brevity):

• 实际上，有些工具将第一行作为主题行，将第二段作为正文(类似于电子邮件).
• git log不处理换行，因此如果行太长则很难阅读.
• git format-patch --stdout将提交转换为电子邮件-因此，如果您的提交已经被很好地包装，则可以发挥很好的作用.

• In practice, some tools treat the first line as a subject line and the second paragraph as a body (similar to email).
• git log does not handle wrapping, so it is hard to read if lines are too long.
• git format-patch --stdout converts commits to email — so to play nice it helps if your commits are already wrapped nicely.

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

A point I would like to add that I think Tim would agree with:

• 总结提交的行为是任何版本控制系统中固有的良好做法.它可以帮助其他人(或以后的您)更快地找到相关的提交.

所以，我对这个问题有几个角度:

So, I have a couple of angles to my question:

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

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

My point here is not to recommend the 50/72 style or shoot down other styles. (To be open about it, I do prefer it, but I am open to other ideas.) I just want to get the rationale for why people like or oppose various Git commit message styles. (Feel free to bring up points that haven’t been mentioned, too.)

推荐答案

关于摘要"行(公式中为50)，Linux内核文档

Regarding the "summary" line (the 50 in your formula), the Linux kernel documentation has this to say:

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日志中摘要行长度的直方图:

That said, it seems like kernel maintainers do indeed try to keep things around 50. Here’s a histogram of the lengths of the summary lines in the git log for the kernel:

(查看完整的)

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

There is a smattering of commits that have summary lines that are longer (some much longer) than this plot can hold without making the interesting part look like one single line. (There’s probably some fancy statistical technique for incorporating that data here but oh well… :-)

如果要查看原始长度:

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提交消息:50/72格式化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！