gitのコミットっていつ、どのぐらいするの？
ソースのバージョン管理といえば、gitと言われるほど定番のgit。
しかし、「いつ、どのぐらいの量をコミットするか？」っていう悩む声も多いと思います。
というか自分は悩みました。
そこで整理がてら、自分のコミット感を紹介したいと思います。
コミットの頻度は？
基本的にコミットは細くすることが、良いと思います。 なぜなら、細く区切りすぎたコミットはあとでrebaseでまとめることができるので、 コミットの頻度としては、多いにこしたことがないと思います。
そして細くした場合のメリットとしては、
- 実装ミスを見つけたときに戻しやすい
- 見返すときに流れが読み取りやすい
- コミットを分けることを意識することで、計画的になる
- 計画的になることで、見積もりや設計がより精度の高いものになる
という感じだと思います。
とは言っても、闇雲に区切っても無駄なのである程度の粒度でまとめる必要があると思います。
コミットの粒度は？
Railsで新規機能実装をする場合を例にすると、モデルもなにもない状態だとだいたい以下の流れでコミットを分割する。
- 各種コードの作成 (scaffold)
- あるルーティングの実装 ( HogesController#index )
- 機能ごとに分割 ( ページングに対応、検索フォーム作成など )
- リファクタリング
- PullRequest or 次のルーティングを実装
2.に関しては、scaffoldであればほとんど出来上がっているので飛ばして、3.へ。
あとは、追加機能であったり、バグフィックスのような実装の場合は、3.だけの1 コミットだったりするんだけど、実装に当たって新しくクラス作成する場合は、そのクラス作成とメソッド実装で一回コミットしています。
GithubやBitbucketでのIssueもそのぐらいの粒度にして、この辺はいろんなところで紹介されている通りです。
コミットするときの注意
実装の意味合いから、実装とテストを分けて考えている人もいるのですが、実装に対応してテストを書くので、実装 + テストは1セット。
よってコミットのときは、テストもセットでコミットする。
どうしてもテストできない場合はpending状態にしてテストだけでも書いておくといいと思います。
