読者です 読者をやめる 読者になる 読者になる

レビュー依頼前のコミット整理方法

Misoca開発チームのmzpです。 新しいMisocaステッカーが完成したので、いろいろな場所で配りはじめました。

今日は、Misoca内でレビュー依頼をする前にやっているコミットの整理について紹介しようと思います。 Misocaの開発の話ですので、GitHubのpull requestベースでのレビューが前提です。

f:id:mzp:20151127110840j:plain

要約

pull requestをレビューしやすくするために、コミットを整理しよう。

方針

  • 最終的な結果だけを残し、途中の試行錯誤の跡を消す
  • 無関係の内容は別のコミットにする

具体的な作戦

自動生成と非自動生成のものは分ける

scaffoldで生成されたものや Gemfile.lock 等の自動で更新されるものは、特にレビューする必要はありません。

そのため、それ以外の手で書いた変更とは別のコミットとは別にしておくとよいです。

試行錯誤の跡を消す

PR内で発生したバグの修正コミットや、Rubocop違反の修正コミットは、元のコミットとfixup/squashして消したほうがよいです。

レビューしてほしい順にコミット順をそろえる。

コミット順に読んでいけば、変更内容が把握できるようにしましょう。

どういう順番が読み易いかは変更する内容によりますが、主に2つの方針があります。

依存している順にコミットしていく

アーキテクチャの内側から外側に向っていくようにコミットを整理していく方針です。

存在していないメソッドを利用するコミットがなくなるので、読み易くなります。

だいたいの場合、以下のような順番になります。

  1. Gemfile の更新
  2. 設定ファイルの更新
  3. modelへの変更
  4. controller/viewの変更

ユーザの操作単位ごとにコミットしていく

機能・ページ単位でユーザーが利用する塊に分けてコミットを整理していく方針です。

メソッドがどのように使われているかが、1コミットで分かるようになります。ただし、1ファイルを複数コミットで触っているとrebaseが難しくなるので、注意が必要です。

便利なgitコマンド

コミットを整理する際に便利なgitコマンドを紹介していきます。

コミットを最初からやりなおす

コミットが積まれすぎると、rebaseするのは大変です。 その場合は、いったんresetしてから個別でコミットしていくのが便利です。

git reset origin/master
git add -p app/models
git commit -m '.....'

githubのcommitsとコミット順を揃える

GitHubのpull requestのcommitsはコミット順ではなく日付順なので、たまにずれたりします。その場合は日付を一括でリセットすると、コミット順通りに表示できるようになります。

git rebase --ignore-date  origin/master