少数精鋭チームにおける コミット戦略 〜マイクロコミットのすすめ〜
少数精鋭チームとは？
- 各自が自分の裁量の範囲内で自走出来るチーム
- 必ずしも優秀なひとが集まっているわけではない
- メンバーのレベル感を合わせる
- コミュニケーションコストが低い
- 極力マネージメントしない
他のメンバーへのサポートを極力少なくする
- 悪い意味では無く、自走してもらっている分個別に動いてもらった方がパフォーマンスが上がる
- サポートが必要なメンバーが多いと、周りのパフォーマンスも落ちる
＝＞自走しているとは言えない - 相談が必要なところは遠慮無く相談
相談する側のスキルとして、パッとプルリクのメッセージを読んで意図を理解できる状態にした上で、相談をする - とはいえ、新しく入ったメンバーはサポートも相談も必要なので そこは割り切る必要がある
コミット戦略ってなに？
- コミット粒度
- プルリクエスト粒度
- コミットメッセージルール
をチームにあった形でルール決めする事
コミット粒度
マイクロコミット
特定の一つの意図に対しての修正のみを小さな単位でコミットすること
メリット
他の人がレビューするときにコミット単位での意図を理解しやすい
コンフリクトが起きにくくなる
特定の一つの意図に対してのコミットであれば チェリーピックもしやすくなる
プルリクエスト粒度
マイクロプルリクエスト
特定の一つの意図に対しての修正のみを小さな単位でプルリクエストにする
メリット
マージによる影響が最小限になる
戻すことも簡単
コンフリクトが起きにくくなる
なぜマイクロコミット、マイクロプルリクエスト？
それは本来とは少し違った解釈になりますが、驚き最小の原則というのがありまして
- 大きなコミット・マージは周囲も驚く
- コンフリクトも起きる可能性がさがる
- レビュー工数が低くなる
などのメリットがある
具体例
こんな感じのプルリクで
こんな感じのコミット
ボーイスカウト・ルールは？？？
ボーイスカウトルールとは
ボーイスカウトのルールには、大切なことがあります。
それは、「来た時よりも美しく」です。
開発で言うとリファクタリングに当たります。
ボーイスカウト・ルールは（やりません）
プルリクやコミットに同時にリファクタリングを紛れ込ませることは、それだけ理解しにくいコードをコミットすることになります
リファクタリングをしたい場合はリファクタリングのみのプルリクエストで対応します
コミットメッセージルール
いつ（When）
タイムスタンプで分かる
どこで（Where）
ファイル名とディレクトリで分かる
誰が（Who）
author（作者）で分かる
何を（What）
コミットのタイトル（Subject）とコミットの本文（Body）で分かる
なぜ（Why）
コミットの本文（Body）で分かる
どうやって（How）
コードやdiffで分かる
このようにW51Hのルールがあります。
コミットメッセージルール（やりません！）
コミットの情報を見ることで、ほとんどの情報はとれますし
マイクロコミットの場合、コミット自体がおっくうになってしまう可能性があるためです。
プルリクエストルール
プルリクエストには、若干のルールがあります。
- 関連ISSUEを入れる
- このプルリクエストで何が入るか
- このプルリクエストを入れたらどこに影響が出るか
- これらの情報をソースに手を入れる前にプルリクエストを作成してしまう => WIP Pull Requestフローを採用
プルリクエスト具体例
まとめ
自分にメリット
コンフリクトが起きにくくなって、精神衛生安定します。
小さな単位で本番に入っていくので、ブランチの手離れが早いです。
他人にメリット
空気を吸うように他のメンバーの修正が入ってきます。
レビューもしやすくなります。