こんにちは。
自称コミットオプティマイズドアドバイザーの古里です。
今日は、「良い」コミットと「悪い」コミットについて話していこうと思います。
PR（プルリクエスト）のレビューを幾度となく経験した上で、良いコミットと悪いコミットを言語化してみました。良いコミットを知る前に、まずは悪いコミットの例を見て、理解を深めましょう。
「悪い」コミットの例
悪いコミットの典型例です。
① 適当なコミットメッセージ
例: fix、update、変更した
- 何を修正したのか、どの部分を更新したのかが分かりません
- 何のためのコミットなのかもわかりません
- レビュワーからするとブチギレ案件です
② 変更点が多すぎるコミット
例:1000行以上の変更を1コミットに詰め込む
- 1つのコミットに異なる機能の変更やリファクタリングが混在しているとカオスです
- 差分を適切に管理できないため、デバッグ時に影響範囲を特定しにくくなるなります
- 変更点多すぎなんじゃぼけ案件です
- レビュワーも人間ですので、往々にして後回しにされます
大規模な修正で本当に1000行以上の変更が必要な際は例外です。
③複数のコンテキストが含まれているコミット
コンテキストという抽象的な単語を使いましたが、ここでのコンテキストは、「目的・背景・意図」の意味で利用しています。
例えば、1つのコミットに「新規機能」と「リファクタリング」が含まれていると、2つのコンテキストがあると解釈します。②の話とも被るのですが、同じような修正なのだが、意図が異なる場合、別のコミットに分けて欲しいと思うのです。
「良い」コミットとは
では、良いコミットとは何か？ それを実現するためのポイントを紹介します。
① 「1コミット＝1コンテキスト」の原則
これが一番伝えたいことです。
- 1つのコミットに1つのコンテキスト（目的・背景・意図）を持たせる
- 修正とリファクタリングを混ぜない（バグ修正とコード整理を同時にしない）
- 小さな変更単位でコミットすることで、レビューの負担を減らし、問題が発生した際の原因特定を容易にする
② コミットメッセージにはPrefixを
-
例:
[fix] バグの修正,[feat] ログイン機能の追加,[refactor] コード整理 - コミットの意図を明確にし、履歴を追いやすくする
- チームで統一したルールを決めることで、誰が見ても分かりやすい履歴を作れる
③ コミットメッセージは簡潔かつ具体的に
-
例:
fix: APIエンドポイントの認証処理を修正 - 「何を、なぜ変更したか」を含めると、あとから見返したときに役立つ
なぜ悪いコミットが生まれてしまうのか？
ここまで、「良い・悪い」コミットの話をしてきましたが、PRを出す側も意図的に分かりにくくしている訳ではないでしょう。
気づいたら、わかりにくいコミットが生まれている状況なのです。この理由については、コミット単体ではなく、タスクの切り分け方にも問題があると考えます。
つまり、PRを出す側ではなく、そもそもタスク依頼者側にも問題があるのではないか？という話です。
タスクの適切な粒度
- アジャイル開発におけるPBI（プロダクトバックログアイテム）の設定の見直し
- 1つのPBIが適切な粒度で設計されていれば、それに対応するコミットも自然と適切なサイズになる
- 「1コミット＝1コンテキスト」を実践するためには、タスク自体の設計を適切に行うことが重要
変更の論理的なまとまり
- ある機能の追加・修正・削除を、それぞれ適切に分割する
- 変更を積み重ねたときに、履歴が分かりやすくなるように意識する
まとめ
良いコミットは、単に「きれいな履歴を作る」だけではなく、チーム開発においてコミュニケーションコストを下げ、変更を管理しやすくするために重要です。
- 適切なコミットメッセージを書く
- 1コミット1コンテキストを意識する
- コードの変更を論理的に整理する
これらを意識することで、よりスムーズな開発が可能になると考えます！
試してみてね♡
宣伝
Organizationやってます。