プロのように Git コミットメッセージを書く最良の方法

開発者が6ヶ月前に取り組んだ何かを振り返るとき、多くの場合、なぜその特定のコミットを行ったのか理解できないことがあります。その唯一の理由は、コミットメッセージを正しく書く方法に従わなかったからです。

\ 世界中の開発者が実践しているコミットメッセージの標準があり、人気のある標準に従うことは良いことです。そうすれば、長い時間が経った後に戻ってきたとき、または他の人があなたのコミットメッセージを見たとき、それらは不快に見えないでしょう！

\

\ チームはまず、構築している製品のバージョン管理履歴を指定するコミットメッセージの規約を決定する必要があります。

\ 優れたGitコミットメッセージには、適切なスタイル、内容、メタデータが必要です。

\ 一般的なGitコミットは次の規約に従います：

<タイプ>(<スコープ>): <メッセージ>

\ <タイプ>は以下のいずれかになります：

• feat 新機能の場合。
• refactor 本番コードのリファクタリング（例：関数名の変更）の場合。
• docs ドキュメントの変更の場合。
• fix ユーザーのためのバグ修正の場合。
• perf パフォーマンス改善の場合。
• style フォーマットの変更、セミコロンの欠落などの場合。
• test 不足しているテストの追加、テストのリファクタリングの場合。
• build ビルド設定、開発ツール、またはユーザーに関係のない他の変更の更新の場合。

\ チームが従う標準に応じて、カスタムタイプを追加することもできます。上記の標準はESLintチームによって採用されています。彼らのコミットメッセージをここで確認できます。

\ スコープはオプションであり、メッセージ部分にはコミットの目的を要約する72文字以内の一行の文を含める必要があります。

\ 多くの開発者はメッセージを件名行として使用し、本文も追加します。これは基本的にコミットの説明ですが、コンテキスト（コミットの内容と理由）を理解できる限り、一行のコミットメッセージが望ましいです。コミットが一行では説明できない詳細な説明を必要とする場合、コミット本文は常に必要です。

\ GlitterやCommitizenなどのツールを使用して、コミットメッセージを標準化することもできます。

\ それだけでなく、コミットメッセージをチェックし、ガイドラインに従っていない場合にエラーを表示するツールがあるかどうか疑問に思うかもしれません。Commit lintはそのひとつです。これはチームがコミット規約を守るのに役立ちます。

\ 多くの場合、業界の専門家はJIRAやClick Upチケットをコミットメッセージとして使用し、いつでもすべてをリンクまたはトレースバックできるようにし、コードベースが将来の開発者のために保守可能な状態を保ちます。

\ 一部のチームはコミットメッセージに絵文字を追加することも好みます。私は絵文字とそれぞれの意味のリストをまとめました。ここで確認できます。

\ 最終的に重要なのは、コミットメッセージが意味のあるものであり、特定の変更が何についてのものかについて、同僚の開発者や将来の開発者を混乱させないことです。

\ 従来のコミット、セマンティックコミット、または業界が従う慣行についてもっと学びたい場合は、以下のリソースがあります：

1. Conventional Commits
2. Semantic Commits
3. How to write a commit message by CBeams

\