私はその質問をするのに苦労しましたが、ここにあります。数年前から、さまざまなシステム（svn、hg、git）を使用する複数のプロジェクトでソース管理を使用しており、ガイドラインなどに従ってメッセージを改善する方法を学びました。しかし、覚えている限り、後でそれらを確認したことはありません。 。
それで...あなたはあなた自身のコミットメッセージからどのように利益を得ますか？何かを壊して新たなスタートが必要なために戻る必要がある場合、通常は最新の「ノード」（ブランチを開始またはマージした場所）に戻るだけです。何が起こっているのか興味があるプロジェクトを監視している人々のためだけにそれらのメッセージを書きますか？
よろしく
あなたは自分の将来の自分やチームの他の人への援助としてそれらを書きます。私がそれらを有用だと思ったときの背景をあなたに与えるために：
私は以前、コミットメッセージが非常に貴重なプロジェクトに取り組んでいました。何度も、コミットメッセージを使用して古いコードを追跡していました。そのプロジェクトでは、バグ追跡システムもVCS（ClearCase）と統合されました。したがって、変更をチェックインすると、コミットコメントにバグ番号が記録されます。これは、何が変更されたのか、そしてその理由を正確にさかのぼることができるようにするのに非常に役立ちました。
要約すると、コミットメッセージは、始めたばかりの場合（特に、プロジェクトに取り組んでいるのが1人だけの場合）は無意味に見えるかもしれませんが、複数の開発者によって本番環境でサポートされている製品が成功すると、非常に貴重になります。
アップデート
コミットメッセージのもう1つの便利な機能は、今行った変更を確認して要約する必要があることです。変更内容を覚えていても、チェックインする前にファイルを簡単に比較することがよくあります。タイプミスがないこと、意図したことをすべて変更したことなどを確認するために、ファイルをもう一度簡単に読み直します。これは、コードに侵入する可能性のある小さな小さなバグがないかコードを確認する簡単な方法です。とにかく、これを行った後、私は何が変更されたかを明確に把握しているので、ファイルをチェックインするときに変更の簡潔な要約を書くためにこれを使用します。これは、あなたの側で少しの努力でコード品質を向上させるのに役立つ単純な習慣です。
「過去2週間に行ったことのリストを送ってください」-ボス
あなたのメッセージはあなた自身よりも他のユーザーのためのものです。私は個人的なリポジトリにも良いコミットメッセージを置くようにしていますが。プロジェクトに取り残されて、数か月後にプロジェクトにアクセスして、プロジェクトで行われた最近の作業を処理するときに役立ちます。
私が見つけた1つのことは、コミットメッセージは、自分が十分な頻度でコミットしないのを防ぐ良い方法であるということです。変更を短いコミットメッセージに入れることができない場合は、おそらく以前に変更をコミットする必要があります。
それが何であるかをあなたに伝えるためのメモなしのコミットのポイントは何でしょうか？これは、「なぜ本の横にタイトルがあるのか」、または「なぜ本に索引とページ番号があるのか」と尋ねるようなものです。各変更の説明がないソース管理ログはあまり役に立たないように思われます。
コミットメッセージを参照する必要がある理由は次のとおりです。
これらの可能性のいずれについても、適切なコミットメッセージがなければ、コードで探しているものが見つかるまで、すべてのコミットの差分を調べたままになります。
最良の場合、コミットは機能/バグトラッカーの作業項目にバインドされます。そうすれば、どの機能/バグが実装/修正されたかを簡単に確認できます。これは、特定のリビジョンに機能やバグ修正が含まれているかどうかを知るだけでなく、リリースノートを簡単に作成するのにも役立ちます。