はじめに
最近、表題のようなプルリクエストと格闘していたことがありました。そこで得た学びを備忘録的にここに書きます。
連なったプルリクエストとは？
まず、連なったプルリクエストとは何か？について説明します。ここで言う連なったプルリクエストとは、
mainから生えた子ブランチAがブランチBの親で、ブランチBが親のブランチCがあり...と言った感じで、派生ブランチの連鎖が起きているような状態です。
通常ではmainに向けPRを発行すれば問題ないかもしれません。しかし、これらは上流ブランチに依存関係のあるコンポーネントを抱えており、それがmainにまだマージされていない場合に、こう言った事態が発生することがあるかと思います。
何が起きるのか
チームはレビューにかける時間が増大してしまう
レビュアーは順に追って見なければならなかったり、1つのPRあたりのdiffが膨大になっている場合などではレビュアーが全てのPRを見終わるまで時間がかかってしまいます。こうなるとチームのレビューのキャパシティを超えることにもなり、他のPRまで滞留が始まってしまいます。
PR作成者側はmainにコミットがされた場合、rebaseやコンフリクト対応に追われる
こうなってしまうと、PR作成者側にも大きな負担がかかります。
また、例えばbranchCの親のbranchBのPRで、かつbranchCに影響のあるコンポーネントに修正を依頼するコメントが来た場合でも、修正の必要や、commitをrebaseなどする可能性が出てくることもあるでしょう。その場合でも対応が煩雑になることが考えられます。
どうすれば防げるか？
そもそも何故連らせているのか？を考える
実は後になって、親子関係にするほどそこまで依存度の高くないコンポーネントだった、ということがあるかもしれません。
それぞれの機能において影響のあるものを洗い出しておきましょう。
それでも連なってしまった場合は、最初の1つのPRだけをOpenにして、それ以外のPRはDraftにする
こうすると、レビュアーは最初の１つのPRのレビューに集中することができ、早期のレビュー完了、マージの一助になります。
mainにまだマージされていない内容に依存するようなタスクを、レビューとマージが完了するまでそのスプリントでは取らない
少々強めの解決策ですが、これも選択肢の1つとしてあるかなと感じます。レビューにかかる時間は1つのPRあたり必ず一定時間ありますし、数が多ければそれに比例して増大していきます。そのため、1つ目がマージされるまで着手しないという手もあります。
最後に
チーム開発では、思い通りのフローではいかなくなる時が訪れることがあります。しかしそれを早期に抜け出し、円滑に進めていくことが最終的なベロシティ向上につながっていきます。