コミットの粒度とは、どの程度の変更をひとつのコミットにまとめるかということです。コミットの粒度が細かすぎる(些細な変更で毎回コミットする)と、コミットログが肥大化し、管理が煩雑になる可能性があります。逆に、粒度が粗すぎる(何百行にもわたるような変更をコミットする)と、変更履歴が意味をなさなくなる場合があります。
では、どのような粒度でコミットを行えばよいのでしょうか？その判断基準として以下のようなポイントを考えてみましょう。
大前提として、コミットする際は正常に動作することを最低限確認しましょう。どうしても、動作しないままコミットしたかったり、リモートリポジトリに作業過程でプッシュをして助けを求めたい場合などは、コミットメッセージに WIP などの記述を入れて誰からでも作業中であることをわかるようにしましょう。
コミットは意味のある単位で行うと良いでしょう。例えば、以下のような単位が挙げられます。
- ある関数を変更
- その関数にまつわる処理を同じコミットにまとめても良いでしょう。
- あるボタンを追加
- そのボタンを押した時の処理、ボタンの見た目など、ボタンにまつわる処理を同じコミットにまとめるのが良いでしょう。
共同開発では、プルリクエストを通してコードレビューを行うことが多いです。そのため、レビューアー視点に立ってレビューしやすい単位でコミットを行うと良いかもしれません。また、それが自然と適切なコミットの粒度となっていることも多いです。 自分がコードを読む側だとして、どこまでの変更範囲が一つのコミットだったらレビューしやすいかを考えてみましょう。
コミットにまとめる変更の種類によって、粒度の判断が変わってきます。例えば、以下のような種類が挙げられます。
- 単純なタイポ修正など、小さな修正
- 新規機能の実装、大幅な変更
- バグ修正
- リファクタリングなど、コードの整理
小さな修正(Typo など)については、複数の変更をひとつのコミットにまとめても問題ない場合があります。しかし、大幅な変更や重要な機能の追加など、影響が大きい変更については、一つずつ丁寧な規模でコミットを行った方が良いでしょう。
チームの開発スタイルによっても、コミットの粒度は変わってきます。例えば、単独で開発を行っている場合は、割と大雑把なコミットでも許されるかもしれません。
一方で、複数人で開発を行う場合は、コミットログの意味を共有する必要があります。そのため、チームで話し合って、共通のルールを決めておくことが重要です。