2017.06.09

ReadableなPull Requestを作る為に心がけていること②

mmmuser

前田です。
来週月曜日から久しぶりに社員全員で集まってローカルワークする予定なので今からwktkです。

以前書いた「ReadableなPull Requestを作る為に心がけていること」の追加で少し書きたいことがあったので追加で書きます。
前回「Pull Request(以下PR)を見やすくする為に粒度を小さくする」ことを心がけている、と書きました。
そんな、タスクの粒度が大きくてPRを細かくした時に行っているちょっとしたGitHubの運用ノウハウを紹介します。

Contents

１つのタスクを細かくするとどうなるか
各PRで修正が入った時はどうするか
マージする時に気を付ける

１つのタスクを細かくするとどうなるか

① 分割した機能を実装するPR1をmasterブランチから切る
② PR1の機能を実装
③ 分割した機能を実装するPR2を**(PR1で実装した機能を使いたいので)PR1ブランチから切る
④ PR2の機能を実装
⑤ 分割した機能を実装するPR3を(PR2で実装した機能を使いたいので)**PR2ブランチから切る

そうすると以下のような状態になります。

この場合の問題は、PR2のmasterとの差分がPR1と被っている、PR3のmasterとの差分がPR1・PR2と被っている、ということです。
PR1をmasterにマージすればPR2は見やすくなっているのですが、レビューが中々進まない時はPR1がmasterにマージ出来ないので図のような状態になってしまいます。
コードの差分が重複しているとレビューアが「あれ、さっきもこのPR見たような。。？」などと混乱してしまい、差分もたくさんあり見ずらいPRになってしまいます。

解決方法は簡単で、PR先を以下のように変えることです。

こうすることで、PR2・PR3の差分が見やすくなります。

各PRで修正が入った時はどうするか

たとえばPR1で修正が入った時はどうするか。

PR1で修正をコミット後、PR2はPR1からrebaseし、PR3はPR2からrebaseします。

コンフリクトすることもあり、ちょっと面倒ですが子PRをrebaseしていきます。
コンフリクトがたくさん出て大変な時はcherry-pickで解決するのがいいと思います。

例 : PR2からPR3のrebaseが大変な時
PR2から新しくブランチ(PR3_1)を切る → PR3から必要なコミットをPR3_1にcherry-pick → PR3を削除

マージする時に気を付ける

マージする時には気を付けないといけません。
例えばPR1のレビューが終わり、PR1をmasterにマージしてcloseすると、PR1に対してリクエストしているPR2が自動でcloseされ、PR2に対してリクエストしているPR3が自動でcloseされます。
なので、正しい手順はPR1をmasterにマージする前にPR2のマージ先をmasterに変えてあげる必要があります。