LoginSignup
4

More than 5 years have passed since last update.

非常に大きなfeatureブランチをフォルダ毎にレビューする

Posted at

背景

大きな機能の実装が完了し、数ヶ月前に切ったfeatureブランチをdevelopに取り込む時が来ました。しかし、そのままGitHubでPull Requestを出すと...変更が多すぎて表示に非常に時間がかかり、とてもレビューしづらい状態でした。あまりにも差分が大きい場合は一部しかコードが表示されないこともありますよね(※)。そもそもこんな大きな差分はレビューの粒度としても不適切ですし、分割してレビューしてもらうことにしました。

(※上限についてはGitHub公式サイトにまとまっています。)

具体的には今回作業を行ったのはiOSアプリのリポジトリで、変更内容は以下のような感じでした。

  • CocoaPodsでのライブラリ追加
  • 画像や音声などのリソースファイルの追加
  • Embedded Frameworkの作成と追加
  • アプリ本体のコードの変更

これらは、例えばCocoaPodsでのライブラリ追加だったらPodsフォルダの下、という風にフォルダで別れていたので、フォルダごとにPull Requestを作成できないか考えました。

フォルダ毎にPull Requestを出す

前提として機能開発ブランチを featureA とし、コンフリクトは解消されているとします。

STEP 0: featureAにタグをつける

作業開始地点にタグをつけておきます。(必須ではありませんが、featureAで微調整が続いているような場合に分かりやすくなります。)

git checkout featureA
git tag featureA_alpa

out-1.png

STEP 1: developからbaseブランチを切る

git checkout develop
git branch base

STEP 2: developからcompareブランチを切る

git checkout -b compare

out-3.png

STEP 3: compareブランチにfeatureAをマージ

git merge featureA_alpa

out-4.png

STEP 4: baseブランチにレビュー対象フォルダ以外を取り込む

ここがポイントです!
例えば Sources 以下がレビューしてもらいたい対象の場合は次のようにします。

git checkout base
git checkout compare ":(exclude)Sources"
git commit

checkout時にパス(複数可)を指定すると、ブランチは切り替わらずに指定したファイル・フォルダの内容のみを持って来れます。 :(exclude) をつけるとそのパスを除外するという意味になります。

out-5.png

STEP 5: compareブランチにbaseブランチをマージ

これによってSources以下の変更だけが差分として表示されるようになります。

git checkout compare
git merge base
git tag review_start

out-7.png

STEP 6: pushしてPull Request !

base ブランチと compareブランチをpushしてGitHub上でPull Requestを作成します。

git push origin base
git push origin compare

これでSources以下の変更のみがPull Requestに表示されるようになりました!

STEP 7: レビュー & 修正

いつも通りGitHub上でコメントのやりとりやコードレビューを進め、指摘の修正を compare ブランチに行っていきます。
out-9.png
チーム開発をしているとこの間にもdevelopやfeatureAも進んで行ったりしますね!(もっともfeatureAに関してはレビュー対象のフォルダへの変更はちょっと待ってもらいました。)

STEP 8: 修正分をfeatureAに取り込む

修正分のコミットを featureAにリベースします。

git rebase --onto featureA_alpa review_start compare

out-10.png

compare ブランチを featureA にマージします。(必要ならPull Requestを出しましょう。)

git checkout featureA
git merge compare

out-12.png

これでSources以下はレビュー済みの状態になりました!

後はレビューが必要なフォルダについてこれを繰り返し、全て完了したら featureAブランチを develop に取り込みましょう!

foldermarge2
せっかくなのでGIFアニメにしてみました。

Pros & Cons

この方法だとレビュー対象のブランチ comparefeatureA の内容を全て含んでいるため、ビルドしての動作確認が可能です。新機能の仕様をよく知らないレビュワーにとって実際に動かせるのは大きなメリットです。

一方、各Pull Requestの結合部分については議論しにくいので、どう分割するかが大切になります。もし新しく作成したモジュールのインターフェースをレビューしてもらいたいなら、モジュールと利用部分の両方が含まれるようにすると良いかもしれません。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4