私は非常に多くのファイル (60 を超えるが 70 未満) を管理していることに気づき、これまでのコミット メッセージは次のパターンに従っていlayout.cssます。何か、私のコミットメッセージは「layout.cssファイルから何かを削除しました」です。
いくつかのファイルは、コミット フィードを見て、追加...および 削除...メッセージが支配的です。一度に多くの変更を行うため、何を削除したか、何を追加したかを覚えていないことがありlayout.cssます。そのため、適切なコミット メッセージを思いつくのに苦労しています。
コミットメッセージを作成するために従うべき標準はありますか?
行ったことを説明するだけでは (「関数を追加した」などの技術的であいまいな用語で)、Git が既にコミットに保存しているものに多くを追加していることにはなりません。しばらくしてからコミット メッセージを読んでいる自分を想像してみてください。その変更の本質を他の開発者に伝えたり、覚えたりするのに最も役立つのはどのような要約ですか?! 正確な内容はプロジェクトとプロセスによって異なりますが、これは良いガイドラインです。
したがって、何よりもまず、「追加された frob() 関数」の代わりに、コミット メッセージにコンテキスト ( howではなく、why ) を追加します (たとえば、「持続性を有効にするためにメッセージをフロブナイズします」)。より多くの努力が必要ですが (熟考して考える必要があります)、それ以上の価値があります。
このトピックについて詳しく知りたい場合は、Peter Hutterer によるこのブログ記事やこの面白いスライドなど、豊富な情報があります。
50/72 モデルは良い方法のようです。つまり ... 最初の行は最大 50 文字の長さで、ヘッダーとしてサーバーに送信する必要があります。スペースが続く場合、2 番目の行セットは 72 文字で折り返され、要約として機能する必要があります。ここに SO の質問があります: Git Commit Messages : 50/72 Formatting、同じことについて説明しています。
この件に関するいくつかの徹底的なメモを以下に示します。
Git は、コミットでどのファイルを変更したかを既に認識しています。コメントで指定しても意味がありません。たとえば、「パディングのバグを修正」または「サイドバーにメニューを追加」と言ってください。はっきりさせて、それだけです。