GitHubチーム開発 プルリクエスト間の依存性がある場合、どうするのが良いのか。

Question

チーム開発で、GitHubを使い始めました。

主な開発手法

2人で開発しており、mainブランチに対して、issueごとにブランチを切って、プルリクエストを投げ、お互いのコードをレビューしあって、コードの品質を保証するというやり方をしています。

プルリクエストが承認された場合、各開発ブランチはmainをrebaseで取り込むということを行い、mainとの差分を適切なものに維持します。

起きている問題

プルリクエスト間の依存性

mainへのマージにはレビューが必須なため、片方がレビューが遅れるとプルリクエストが溜まってしまい、以前投げたプルリクエストの変更に依存性があるプルリクエストが発生することになりました。

試した方法

この場合、依存性のあるブランチに対して、プルリクエストを投げるというやり方で、直接mainに対してプルリクエストを投げないようにし、1つめのブランチと差分もGitHub上で見れるようするという解決方法を取りました。

しかし、そうすると、1つ目のプルリクエストで修正があった場合、後ろに続くプルリクエストでコンフリクトが多発するようになり、レビューの効率が大きく下がりました。

質問内容

このような状況では、プルリクエスト間で依存性があるものを開発する場合、手前のプルリクエストが承認されるのを待つ。というのが正しいのでしょうか。

他によい管理方法があれば教えていただきたいです。

Comments

[Zuishin]

ボトルネックがあるのであればそこのレビューを最優先で終わらせる他ないと思いますが、開発する人を一人レビューに回せばいいのではないでしょうか。

[Kchan_01]

自分で投げたプルリクエストに対して、自分でレビューをするということでしょうか。セルフレビューはプルリクエストを投げる際に行っているので、その方法を取ってしまうと、レビューを挟んでいる意味がなくなります。

[Zuishin]

一人が開発をやめてレビューに専念するということです。

[Kchan_01]

プルリクエストを優先していますが、それでも多忙でこのような状況が起きているという前提です。
つまりレビューが開発スピードのボトルネックになっているという状況です。

[Zuishin]

一人が暇で開発しすぎて忙しい方のレビューが追いつかないということですか？
どちらもレビューできるのであれば、速い方がレビュー専門になれば片付くと思います。
人を増やすのが根本な解決になるとは思いますが。

Answer 1

、1つ目のプルリクエストで修正があった場合、後ろに続くプルリクエストでコンフリクトが多発するようになり

それは案件の切り分け方が適切ではないからです。同じファイルをいじらないようにするのがベストですが、それも難しい場合は極めて細かい単位(数commitごと)で後ろに続くプルリクエストをmergeし続けることで緩和できます。この場合は大本のPRのレビューを関係者全員でレビューし直してmergeしたほうがいいでしょう。