今日は私がつい先日経験した「コミットメッセージあるある悲劇」についてお話しします。
思わず「あ、やってるかも...」と思った方はこれを機に見直してみましょう！

「fix」だけで命を削られた日々

先月のことです。大規模なプロジェクトで新機能の開発をしていた私。2週間ほど黙々とコードを書き、ようやく完成！あとはmainブランチの最新変更を取り込んで、プルリクを出すだけ...と思っていました。

そう、「思っていた」だけなんです。実際には...

$ git rebase main
Auto-merging src/components/UserProfile.tsx
CONFLICT (content): Merge conflict in src/components/UserProfile.tsx
Auto-merging src/api/userService.ts
CONFLICT (content): Merge conflict in src/api/userService.ts
...（以下、コンフリクト祭りが続く）

「まぁ、仕方ない。1つずつ解決していくか〜」と思い、コンフリクトの原因となったコミットを確認しようとしたんです。

そこで目にしたのが...

...はい、こんな「何も伝わらない」コミットメッセージの嵐でした。
もうこの時点で「あぁ、終わった...」と悟りましたね（遠い目）

「え、このコミット何直したの？」問題

皆さん、こんな経験ありませんか？

「fix」というコミットを見て「何を直したの？どこを？なぜ？」と天に問いかける瞬間
「指摘修正」を見て「誰の？どんな指摘？どうして？」とモニターに向かって叫びたくなる衝動
「修正しました」というメッセージを読んで「それ言ったら全部"修正"やん！」とツッコミを入れたくなる瞬間ありますよね？

実はこの「何も伝わらないコミットメッセージ問題」、個人開発ならまだしも、チーム開発では本当に致命的なんです。

私が味わった「修正地獄」

話を戻しますと、私は各コンフリクトを解決するために、一体何が変更されたのかを理解する必要がありました。でも、コミットメッセージからは何も分からない...

結局どうなったか？

コンフリクトが起きているファイルの変更履歴を一つ一つ調査
関係者に「このコミット何したの？」とSlackで片っ端から質問
コンフリクト解決に丸1日を費やす羽目に...

本来30分で終わるはずだった作業が、8時間以上に...

こんな時間の無駄、もう二度と経験したくないです...

「ちゃんと書くとどうなるの？」の実例

それでは、良いコミットメッセージとはどんなものか見てみましょう。

feat: ユーザープロフィール画面の住所入力機能を実装
郵便番号による住所自動入力機能を追加
バリデーション処理の実装
テストケース追加
デザインはFigmaのデザイン通りに実装（#123のデザイン）

これを見ると、一目でどんな変更かわかりますよね！「なるほど、ユーザープロフィールの住所入力関連の実装なんだな」と。

悪い例と良い例を比べてみましょう。

悪い例:
fix: バグ修正

良い例:
fix: 商品一覧画面で価格が表示されないバグの修正
商品データ取得時のAPIレスポンス形式変更への対応が漏れていたため修正。
price属性の取得方法を変更し、undefinedの場合は0円表示するよう修正。

どっちが分かりやすいか、言うまでもないですね。

「なんでそんなに重要なの？」という声が聞こえてきそうなので

「いやいや、そこまで気にすることなの？」と思うあなた。実はこれ、本当に大事なんです。

1. コンフリクト解決が格段に楽になる

「feat: 商品詳細画面のレイアウト修正」というコミットなら、コンフリクト時に「ああ、これはUIの見た目を良くするための変更だったんだな」と即座に理解できます。

2. 新メンバーの「つらみ」が減る

プロジェクトに新しく参加した人が過去のコードを見るとき、「なぜこの変更がされたのか」が分かれば、コードベース理解のスピードが段違いに速くなります。

3. 未来の自分への最高の贈り物

3ヶ月後の自分が「なんでこんなコード書いたんだっけ...」と悩まずに済みます。これ、地味に大きいですよ（自戒を込めて）。

明日から使える！コミットメッセージの書き方

では、どうすれば良いコミットメッセージが書けるのか？シンプルな3ステップです。

1. プレフィックスをつける

feat: 新機能
fix: バグ修正
docs: ドキュメント関連
style: コードスタイル修正（動作に影響なし）
refactor: リファクタリング（動作に影響なし）
test: テスト関連
chore: ビルドプロセスや補助ツールの変更

2. 何を変更したかを具体的に書く

「ユーザー登録画面のバリデーション処理追加」のように、どのファイル・機能に関する変更かを明記。

3. なぜ変更したかも書く（必要に応じて）

「IE11でレイアウトが崩れる問題があったため」など、変更の理由も書くとさらにGood！

チームで始める「コミットメッセージ改革」

個人の努力も大事ですが、チーム全体で取り組むともっと効果的です

コミットメッセージテンプレートを作る
.gitmessageファイルを作って、チーム共通のテンプレートを設定しましょう。
レビュー時にコミットメッセージもチェック
コードレビューの際に「このコミットメッセージ、もうちょっと詳しく書いてもらえる？」とフィードバックする文化を作りましょう。
良いコミットメッセージの例を共有する
チーム内で「これは良いコミットメッセージだね！」と褒め合う、そんな前向きな文化も大事です。

最後に

小さな努力が大きな効果を生む

「コミットメッセージを丁寧に書く」という、たった数分の追加作業。でも、それがプロジェクト全体の効率と品質を大きく左右することを、身をもって体験しました。

今日からさっそく、あなたのコミットメッセージを見直してみませんか？

「fix」だけのコミットメッセージを見て、未来の同僚や自分が泣くことのないように...（切実）