Gitコミットメッセージ：50/72のフォーマット

Tim Popeは彼のブログ投稿で特定のGitコミットメッセージスタイルを主張しています：http : //www.tpope.net/node/106。

これが彼が推奨することの簡単な要約です：

• 最初の行は50文字以下です。
• 次に空白行。
• 残りのテキストは72文字で折り返す必要があります。

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

• 実際には、一部のツールは最初の行を件名行として扱い、2番目の段落を本文として扱います（電子メールと同様）。
• git log は折り返しを処理しないため、行が長すぎると読みにくくなります。
• git format-patch --stdout コミットを電子メールに変換します—うまくプレイするために、コミットが既にうまくラップされている場合に役立ちます。

ティムが同意するだろうと私が付け加えたい点：

• コミットを要約することは、本質的にどのバージョン管理システムでも良い習慣です。他の人（または後であなた）が関連するコミットをよりすばやく見つけるのに役立ちます。

だから、私は私の質問にいくつかの角度を持っています：

• Gitの「思想的リーダー」または「経験豊富なユーザー」のどの部分が（大まかに）50/72フォーマットスタイルを採用していますか？新しいユーザーがコミュニティの慣習を知らないか、気にしないので、これをお願いします。
• このフォーマットを使用しない場合、別のフォーマットスタイルを使用する主な理由はありますか？（私は「私はそれを聞いたことがない」または「私は気にしない」ではなく、メリットについての議論を探していることに注意してください。）
• 経験的に言えば、Gitリポジトリの何パーセントがこのスタイルを採用していますか？（誰かがGitHubリポジトリで分析をしたい場合…ヒント、ヒント。）

ここでの私のポイントは、50/72スタイルを推奨したり、他のスタイルを打ち倒したりすることではありません。（それについてオープンにするために、私はそれを好みますが、私は他のアイデアを受け入れます。）人々がさまざまなGitコミットメッセージスタイルを好むまたは反対する理由の根拠を取得したいだけです。（言及されていないポイントも自由にご利用ください。）

「要約」行（式の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ログの要約行の長さのヒストグラムを示します。

（フルサイズで表示）

興味深い部分を1つの線のように見せることなく、このプロットが保持できるよりも長い（場合によってははるかに長い）要約行を持つコミットの断片があります。（おそらく、ここにそのデータを組み込むための素晴らしい統計手法がいくつかありますが、まあ…:-)

生の長さを見たい場合：

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

「思想的指導者」に関して：Linusは、コミットメッセージ全体の改行を強調しています：

[…]特定の行フォーマットを持つ引用された資料を除いて、ワードラップに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.

ビューアでテキストをソフトラップする様子は次のとおりです。

これは要約行です。短くして、改行で終了するようにしてください。

これは、おそらく私が人間が読める形式で行ったことの説明です。それは複雑で長く、私の作品をエッセイ形式で説明するいくつかの文章で構成される場合があります。ユーザーがこのデータをどのように使用するかを今（作成時に）決定するのは私にはありません。

2つの改行がこれら2つの考えを分けています。ユーザーがこれを電話またはワイドスクリーンモニターで読んでいる可能性があります。横60文字しか表示しないデバイスで、72文字の折り返しテキストを読み取ろうとしたことがありますか？本当につらい経験です。また、この段落の冒頭の文（エッセイスタイルの形式を想定）は、段落のイントロダクションである必要があります。そのため、ツールが選択した場合、自動折り返しを行わずに、各段落の始まりだけを表示できます。繰り返しますが、私の特定のフォーマットを他の人の喉に押し付けようとするのは、私（歴史のある時点でのランダムな作者）ではなく、プレゼンテーションツール次第です。

例として、ポイントのリストを以下に示し
ます。
*ポイント1。*ポイント2。
*ポイント3。

私の疑いは、リンクしたGitコミットメッセージの推奨の作成者が、ソフトウェア/コンピューティングの進化のこの時点から、これまでにさまざまなデバイス（つまりWebサイト）でさまざまなエンドユーザーによって消費されるソフトウェアを書いたことがないということです。ユーザーエクスペリエンスに関する限り、ハードコードされたプレゼンテーション情報を使用してデータを保存することは悪い考えです。

特定の働き方を提案するのは面白いと思います。ただし、スタイルを設定する機会がない限り、通常は一貫性を保つために行われたことに従います。

あなたが好きな場合は、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.email-特に内部ネットワーク上。User@ OFFICE-1-PC-10293982811111は便利な連絡先アドレスではありません）。プロジェクトに応じて、コミットで適切な詳細を使用できるようにします。それがどうあるべきかを言うのは難しいです。それは、開発プロセスで完了したタスクであり、次に何が変更されたかの詳細です。

gitへの特定のインターフェイスはコミットを特定の方法で処理するため、ユーザーはgitを1つの方法で使用する必要があるとは思いません。

コミットを見つける方法は他にもあることに注意してください。まず、git diff何が変更されたかを教えてくれます。git log --pretty=format:'%T %cN %ce'のオプションをフォーマットするなどのこともできますgit log。

タイトルの推奨最大長は本当に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以下」を意味するだけであると主張することができます。