gitのコミットメッセージを書くときに従うべき基準 [重複]について

質問

私は非常に多くのファイル(60以上70以下)を管理しており、これまでのコミットメッセージはこのようなパターンに従っていることに気づきました。 のように何かを追加したとき layout.css のように追加した場合、私のコミットメッセージは レイアウト.css ファイルに何かを追加しました。 で、何かを削除すると、コミットメッセージは "layout.cssファイルから何かを削除しました" .

いくつかのファイルの下に、私は自分のコミットフィードを見、そして が追加されました... と を削除しました... のメッセージが支配的です。時々、何を削除したのか、何を追加したのか覚えていないことがありますが layout.css で何を削除し、何を追加したのか覚えていないことがあります。

コミットメッセージを考えるのに役立つ、従うべき標準はありますか？

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

何をしたかを（技術的であいまいな言葉、例えば "関数を追加しました" で）説明するだけでは、Git がすでにコミットに格納しているものにあまり追加していないことになります。後でコミットメッセージを読む自分を想像してみてください。その変更の本質を最もよく思い出し、他の開発者に伝えるために、どのような要約が役立つでしょうか? 正確な内容はあなたのプロジェクトやプロセスに依存しますが、私はこれが良いガイドラインだと思います。

したがって、何よりもまずコンテキストを追加します ( なぜ ではなく どのように ) をコミットメッセージに追加します (例: "added frob() function" ではなく "frobnize the message to enable persistence" )。より手間がかかります（反映させる必要があり を考える を考える必要があります)、しかしそれはより多くの価値があります。

このトピックについてもっと調べたいのであれば、たとえば Peter Hutterer によるこのブログの記事 あるいは この面白いスライド .