Git コミットをする際に適切なメッセージを書くことで
コードベースの理解と保守を容易にし、レビューもしやすくなり作業が円滑に進めやすくなります。
以下は、最近使っているGitのコミット・メッセージのテンプレートです。
Semantic Commit Messagesを参考にしています。
環境
モダン開発環境ではなく、No Frameworkのクラシックな環境で使っています。
Template
[Title]<必須>
[Type]: [Subject] <必須>
# 空白行
[Description]
ルール
厳守
[Type]の後ろに : コロンを付け半角スペースを１つ入れ、[Subject]を記載します。
[Type]: [Subject]
[Type]と[Description]の間に１行分の空白行を入れます。
[Type]: [Subject]
[Description]
Title
Backlogの課題キーと件名やGitHub Issuesなど記載します。
この項目は必須とします。
Type
プレフィックスを付ける形でコミットの種別を記載します。
最初の文字は大文字にする。
この項目は必須とします。
Typeの種類
-
Chore:Projectに影響のないもの、直接な関係のないもの -
Feat:機能の追加 -
Fix:軽微な修正からバグ修正まで含む -
Add:ファイルの追加 -
Change:リネーム、ファイルの削除、フォルダ構成の変更など -
Refactor:非推奨のコード、パフォーマンス改善のためにコードを変更した時 -
Format:空白行消したり、セミコロン付けたり、コードの整形した時など
Subject
変更内容を短く簡潔に書く。
Feat: モーダルの実装
英語の場合は命令形で書くといいそうです。（検索しやすくなるとか）
Feat: Add Implement Modal
Description
やったことを記載します。Subject同様に、短く簡潔にまとめる。
（長くても2行くらいまでに）
この項目は任意ですが、自分が後で見返したり、他の方（レビュワー）が見たときに
タスクの流れが理解できるようにしてください。
背景
私のチームでは人数が少ない事、業務もそこまで複雑でないこともあり、それまで
明確なコミット・ルールはありませんでした。
決まりごとはGitとBacklogの課題を紐づける位です。
そして人数が増え、業務も多岐に渡りと変化していきました。
業務上、過去のプロジェクトを遡る必要があったのですが、課題は発見できるが
「なぜこうしたのか？」が人の記憶に頼る状態であり、尋ねても案の定おぼえてないと。
このままではマズいのでルールを決める流れになりました。
工夫したこと
[Type]の種類は多すぎて、コミットする際に迷いが生じては困るので絞りました。
例えば、修正を意味するFix:も軽微な修正とバグ修正BugFix:とで分かれてたり、
文言修正はdocs:でと紹介しているものが多かった印象ですが、業務の性質など考慮し
修正はFix:でまとめるようにし、[Description]で補足すれば理解できるはず。
また、コード整形などを行った場合はstyle:を使うところが多かったのですが、
こちらも業務の性質上CSSと見間違う可能性があるのでシンプルにFormat:にしました。
感想
まだ使い始めたばかりですが、コミット回数は増えるが今、自分のやってる事が
理解しやすく、戻りが減った感じはあります。
また、チーム・ディレクターからは変更点がわかるので確認しやすくなったと好評。
職種に関係なくチーム全員がプロジェクトの流れを掴みやすくなるって大切ですよね。
テンプレートを使用して、明確で一貫性のあるコミットメッセージを書くことで、
コードベースの保守性を向上させることができます！
参考
Gitのコミットメッセージの書き方（2023年ver.）
Gitのコミットメッセージの書き方
Semantic Commit Messages - Josh Buchea
Semantic Commit Messages - Katie Jennings