先月、会社に一人のフロントエンドの達人が入社し、私たちのチームのために技術面に関するいくつかの規約を制定してくれました。その中の一つに、Git でコードをコミットする際の Commit Message に関する規約がありました。最初は余計なことだと思っていましたが、多くの大規模プロジェクトの Commit 履歴を見て、この規約が業界の標準ともいえるものだと分かりました。
まず、私の CodeStudy プロジェクトではどのような Commit Message を書いているか見てみましょう。
次に、尤雨溪氏の作品である Vue フレームワークの Commit Message を見てみましょう。
やはり、規約に沿った Commit Message は本当に人の目を引き、該当する Commit の内容や関係する機能モジュールをすばやく把握できます。ここでは、規約に沿った Commit Message にどのようなメリットがあるのかについて説明します。
規約化のメリット
- プログラマーがコミット履歴を追跡し、何が起きたのかを把握しやすくなります。
Commit Messageに制約を設けると、毎回のコミットを慎重に行うことになります。さまざまな変更を一つのgit commitにまとめて放り込むことができなくなるため、コード変更の履歴全体もより明確になります。- フォーマット化された
Commit Messageであれば、自動的にChange logを出力するために利用できます。
Git コミット規約
<type>(<scope>): <subject>
<body>
<footer>
| 名称 | 役割 |
|---|---|
| type | Git Commit の種類を説明するために使用し、下表の識別子のみ使用可能です |
| scope | Commit の影響範囲を説明するために使用します。例えばデータ層、制御層、ビュー層などです |
| subject | Commit の目的を簡潔に説明します。通常は 50 文字以内です |
| body | 省略可能で、複数行にできます。詳細な説明を記述し、header との間に空行を入れます |
| footer | 省略可能で、通常は非互換な更新や issue の終了に使用し、body との間に空行を入れます |
| 種類 | 説明 |
|---|---|
| sync | メインラインまたはブランチの bug を同期する |
| merge | コードをマージする |
| revert | 前のバージョンにロールバックする |
| chore | ビルドプロセスまたは補助ツールの変更 |
| test | ソフトウェアテストを追加する |
| perf | パフォーマンスや使用感の向上など、最適化に関する変更 |
| refactor | リファクタリング。新機能の追加でも、bug の修正でもないコード変更 |
| style | コードの実行に影響しないフォーマット関連の変更 |
| docs | ドキュメントの作成または更新 |
| fix / to | bug を修正する。QA が発見した bug の場合も、開発者自身が発見した bug の場合もあります |
| feat | 新機能（feature） |
プラグインのおすすめ
VS Code では、Git Commit Message をすばやく生成できる Commit Message Editor プラグインを強くおすすめします。
