回答:
私が使う
[Abc]: Message.
Add、Mod（ify）、Ref（actoring）、Fix、Rem（ove）、Rea（dability）を使用すると、ログファイルを簡単に抽出できます。
例：
Add: New function to rule the world.
Mod: Add women factor in Domination.ruleTheWorld().
Ref: Extract empathy stuff to an abstract class.
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.
Rem: freeSpeech is not used anymore.
Rea: Removed old TODO and extra space in header.
複数の行がある場合は、最も重要なものから順に並べます。
Modとの違いを教えてくださいRef。時々、リファクタリングのような小さな修正を行うことがあります。
Modは、何かを追加したり、動作を変更したり、機能をRef追加したり、APIを追加したりしない内部的なものを変更することです。例：add(Object)関数があり、関数を実装するadd(List<Object>)場合、コメントしModます。その後、私は重複を削除し、直接使用するadd(Object)にはadd(List<Object>)、私が使用しますRef。
以下を使用します。
[JIRAのチケットID]：[メッセージ：実行内容] たとえば-ABC-123：地域ごとにプレゼンテーションを設定する機能が追加されました。
この場合、適切に統合することで、変更/削除/追加されたファイルを課題トラッカーで取得できます。ただし、ABC-123：完了またはABC-123：可能な場合はフィルターで修正するなどのようなことを防ぐ必要があることに注意してください。
単純なルールが1つあります。これは、多くの（すべてではないにしても）SCMと、SCMで動作するほとんどのツールが従う規則です。
コミットメッセージの最初の行は短い要約であり、残りのメッセージには詳細が含まれています。
そのため、ほとんどのツールは最初の行のみを表示し、メッセージ全体をオンデマンドで表示します。
コミットメッセージの一般的な誤用は、変更の箇条書きリストです（最初の箇条書きのみが表示されます）。もう1つの誤用は、1行に詳細なメッセージを書くことです。
したがって、強制することが1つある場合、それは最初の行の最大長です。
個人的には、使用する価値のある一般的なコミットテンプレートを見たことはありません。コメントは、コミットが何に関連しているか、たとえば、どの機能/バグ修正か、変更が行われた理由の簡単な説明などを簡潔に示す必要があります。
コミットされたものに関する情報を含めるべきではありません。これはscmシステムによって決定できます。より多くのバグ/機能情報は、バグと機能が追跡される場所に属します。
コミット後にバグレポートを更新するときは、バグレポートのコメントとともにコミットリビジョンも記載するのが良いと思います。この方法で、コミットコメントからバグレポートへの道を見つけることができ、バグレポートのコメントごとにコミットされた内容を見つけることができますが、バグレポートとコミットメッセージの両方に情報を含めることで情報を複製しません。
次に、ファイルのリビジョンの履歴を表示すると、履歴を説明する簡潔なメッセージが表示されますが、詳細についてはバグレポートやタスクの説明の詳細を参照できる場所もわかります。
Gitでは、Gitフックを使用してほとんど何でも強制することができます。アイデアについては、.git / hooksの例を確認してください。
メッセージに関しては、非常に一般的なケースでは、解決する問題に関する十分な情報と、このコミットを後で見つけて特定できるソリューション自体を含める必要があります。ほとんどの場合、問題はバグ番号で参照されます（バグ追跡システムと適切に統合されています）。プロセスが統合する他のシステム（コードレビュー追跡システムなど）がある場合は、適切なビットも含めます。
Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.
BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none
しかし、あなたはそれをシンプルに保ちたい。そうでなければ、人々はシステムをだまし、無用なコミットメッセージを生成する方法を見つけるでしょう。
通常、使用するチケット追跡システムにある識別子、または最初の行として高レベルの概要があります。次に、コミットの特定の変更の行項目「箇条書き」ポイントがあります。だから私は次のようなことをすることができます：
MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity
これは、私が好きな最もクリーンなコミット形式です。それは直接的であり、要点です。この方法で行うもう1つの理由は、変更ログを作成する場合、すべてのコミットメッセージを取得して、変更ログに非常に簡単に解析できるからです。
[ticketId] [ABC] [topicId] [WIP]メッセージ、ここで：
例：
[＃452567] [add] [menu_item] new item-guestbook
[＃452363] [fix] [banner_top] [WIP] 1024x300を使用できるようになりました
[＃452363] [fix] [banner_top] 500x200を使用できるようになりました
[ ＃452713] [rem] [page]左中央の広告