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.
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
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.
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… :-)
If you want to see the raw lengths:
cd /path/to/repo
git shortlog | grep -e '^ ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{print length($0)}'
or a text-based histogram:
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
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.
Separation of presentation and data drives my commit messages here.
Your commit message should not be hard-wrapped at any character count and instead line breaks should be used to separate thoughts, paragraphs, etc. as part of the data, not the presentation. In this case, the "data" is the message you are trying to get across and the "presentation" is how the user sees that.
I use a single summary line at the top and I try to keep it short but I don't limit myself to an arbitrary number. It would be far better if Git actually provided a way to store summary messages as a separate entity from the message but since it doesn't I have to hack one in and I use the first line break as the delimiter (luckily, many tools support this means of breaking apart the data).
For the message itself newlines indicate something meaningful in the data. A single newline indicates a start/break in a list and a double newline indicates a new thought/idea.
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.
Here's what it looks like in a viewer that soft wraps the text.
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.
My suspicion is that the author of Git commit message recommendation you linked has never written software that will be consumed by a wide array of end-users on different devices before (i.e., a website) since at this point in the evolution of software/computing it is well known that storing your data with hard-coded presentation information is a bad idea as far as user experience goes.
$ 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”。
Is the maximum recommended title length really 50?
I have believed this for years, but as I just noticed the documentation of "git commit" actually states
$ 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
One could argue that "less then 50" can only mean "no longer than 49".
I'd agree it is interesting to propose a particular style of working. However, unless I have the chance to set the style, I usually follow what's been done for consistency.
I would say consistency matters. Set up proper means of identifying users who've made commits (user.name, user.email - especially on internal networks. User@OFFICE-1-PC-10293982811111 isn't a useful contact address). Depending on the project, make the appropriate detail available in the commit. It's hard to say what that should be; it might be tasks completed in a development process, then details of what's changed.
I don't believe users should use git one way because certain interfaces to git treat the commits in certain ways.
I should also note there are other ways to find commits. For a start, git diff will tell you what's changed. You can also do things like git log --pretty=format:'%T %cN %ce' to format the options of git log.
发布评论
评论（5）
关于“摘要”行（公式中的 50），Linux 内核文档 有话要说：
也就是说，似乎内核维护者确实试图将事情保持在 50 左右。以下是内核 git 日志中摘要行长度的直方图：
有一些提交的摘要行比该图可以容纳的更长（有些长得多），而不使有趣的部分看起来像一行。 （可能有一些奇特的统计技术可以在这里合并这些数据，但是哦……:-)
如果您想查看原始长度：
或基于文本的直方图：
Regarding the “summary” line (the 50 in your formula), the Linux kernel documentation has this to say:
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… :-)
If you want to see the raw lengths:
or a text-based histogram:
关于“思想领袖”： Linus 强烈提倡完整提交的换行信息：
例外主要指“非散文”文本，即不是由人类为提交键入的文本 - 例如，编译器错误消息。
Regarding “thought leaders”: Linus emphatically advocates line wrapping for the full commit message:
The exceptions refers mainly to “non-prose” text, that is, text that was not typed by a human for the commit — for example, compiler error messages.
演示和数据的分离驱动了我在这里的提交消息。
您的提交消息不应以任何字符数进行硬包装，而应使用换行符来分隔想法、段落等，作为数据的一部分，而不是演示文稿的一部分。在这种情况下，“数据”是您试图传达的消息，“演示”是用户如何看待该消息。
我在顶部使用单个摘要行，并尽量保持简短，但我不会将自己限制为任意数字。如果 Git 实际上提供了一种将摘要消息存储为与消息分开的实体的方法，那就更好了，但由于它不是我必须破解的，并且我使用第一个换行符作为分隔符（幸运的是，许多工具都支持这意味着分解数据）。
对于消息本身，换行符表示数据中有意义的内容。单个换行符表示列表中的开始/中断，双换行符表示新的想法/想法。
这是软包装文本的查看器中的外观。
我怀疑您链接的 Git 提交消息推荐的作者从未编写过可以被不同设备上的广泛最终用户使用的软件（即网站），因为在发展的这一点上在软件/计算领域，众所周知，就用户体验而言，用硬编码的表示信息存储数据是一个坏主意。
Separation of presentation and data drives my commit messages here.
Your commit message should not be hard-wrapped at any character count and instead line breaks should be used to separate thoughts, paragraphs, etc. as part of the data, not the presentation. In this case, the "data" is the message you are trying to get across and the "presentation" is how the user sees that.
I use a single summary line at the top and I try to keep it short but I don't limit myself to an arbitrary number. It would be far better if Git actually provided a way to store summary messages as a separate entity from the message but since it doesn't I have to hack one in and I use the first line break as the delimiter (luckily, many tools support this means of breaking apart the data).
For the message itself newlines indicate something meaningful in the data. A single newline indicates a start/break in a list and a double newline indicates a new thought/idea.
Here's what it looks like in a viewer that soft wraps the text.
My suspicion is that the author of Git commit message recommendation you linked has never written software that will be consumed by a wide array of end-users on different devices before (i.e., a website) since at this point in the evolution of software/computing it is well known that storing your data with hard-coded presentation information is a bad idea as far as user experience goes.
推荐的最大标题长度真的是 50 吗？
我多年来一直相信这一点，但正如我刚刚注意到“git commit”的文档实际上指出的那样，
人们可能会说“少于 50”只能意味着“不超过 49”。
Is the maximum recommended title length really 50?
I have believed this for years, but as I just noticed the documentation of "git commit" actually states
One could argue that "less then 50" can only mean "no longer than 49".
我同意提出一种特定的工作方式很有趣。然而，除非我有机会设定风格，否则我通常会遵循已完成的内容以保持一致性。
看一下 Linux 内核提交，如果您愿意的话，该项目启动了 git，http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bca476139d2ded86be146dae09b06e22548b67 f3，他们不遵循 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 的选项。I'd agree it is interesting to propose a particular style of working. However, unless I have the chance to set the style, I usually follow what's been done for consistency.
Taking a look at the Linux Kernel Commits, the project that started git if you like, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bca476139d2ded86be146dae09b06e22548b67f3, they don't follow the 50/72 rule. The first line is 54 characters.
I would say consistency matters. Set up proper means of identifying users who've made commits (user.name, user.email - especially on internal networks. User@OFFICE-1-PC-10293982811111 isn't a useful contact address). Depending on the project, make the appropriate detail available in the commit. It's hard to say what that should be; it might be tasks completed in a development process, then details of what's changed.
I don't believe users should use git one way because certain interfaces to git treat the commits in certain ways.
I should also note there are other ways to find commits. For a start,
git diffwill tell you what's changed. You can also do things likegit log --pretty=format:'%T %cN %ce'to format the options ofgit log.