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