[解決済み】Gitコミットメッセージ。50/72 フォーマット

質問

Tim Popeはブログの中で、特定のGitコミットメッセージのスタイルについて論じています。 http://www.tpope.net/node/106 .

彼が推奨する内容を簡単にまとめると、以下のようになります。

• 1行目は50文字以内
• その後、空白行。
• 残りのテキストは72文字で折り返す。

彼のブログには、これらの推奨事項（簡潔にするために「50/72フォーマット」と呼ぶことにします）の根拠が示されています。

• 実際には、1行目を件名、2段落目を本文として扱うツールもある（メールと同様）。
• git log は折り返しを処理しないので、行が長くなると読みにくくなります。
• git format-patch --stdout はコミットをメールに変換します。そのため、コミットがすでにきれいにラップされていると、うまく機能します。

一点、Timも同意してくれると思うので、付け加えておきます。

• 自分のコミットを要約するという行為は、どんなバージョン管理システムにも本来備わっている良い習慣です。他の人(あるいは後の自分)が関連するコミットをより素早く見つけられるようになります。

そこで、いくつかの角度から質問をさせていただきました。

• Gitの「オピニオンリーダー」や「経験豊富なユーザー」のうち、どの程度が50/72の書式を採用しているのでしょうか？新しいユーザーはコミュニティの慣習を知らなかったり、気にしなかったりすることがあるので、この質問をしました。
• この書式を使用しない場合、別の書式を使用する原則的な理由はありますか？(「聞いたことがない」「どうでもいい」ではなく、そのメリットについての議論を求めていることに注意してください)。
• 経験的に言って、Git リポジトリの何パーセントがこのスタイルを採用していますか？(誰かがGitHubのリポジトリで分析したい場合に備えて...ヒント、ヒント)

私がここで言いたいのは、50/72スタイルを推奨することでも、他のスタイルを非難することでもありません。(ただ、なぜ人々がさまざまな Git のコミットメッセージのスタイルに賛成したり反対したりするのか、その根拠を知りたいだけなのです。(言及されていない点を挙げるのも自由です。)

どのように解決するのか？

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 log のサマリー行の長さのヒストグラムです。

( フルサイズで見る )

このプロットで表示しきれないほど長いサマリー行を持つコミットが散見されますが、興味深い部分は一行に見えます。(そのデータをここに取り込むには、おそらく何か凝った統計的手法があるのでしょうが、まあいいや... :-)

生の長さを見たい場合。

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