Git プルリクエストのマージ先に関して

私のプロジェクトではプルリクエストを小分けにしてレビューコストを下げようと作業改善試しているんですが、案件として以下の様にブランチを派生させていった場合。

feature → A → B

BのプルリクエストをAに向けて作成するとAがマージされてしまった場合、featureに向けてプルリクエストを作成し直さないといけないし、BのPRをfeatureに向けるとAの修正がfeatureに反映されるまで、Aのレビュー内容に含まれてしまってBの修正レビュー箇所がわかりにくくなり不便と思ってるのですが皆さんはどう対処してるのでしょう?

恐らくですが、

feature→ A ┬B
├C
└D

のようにAというある程度の粒度の案件があり、それに対してタスクを小分けにしてブランチを作成していると推測しています。
その場合は、それぞれAに対してPRを作成して全てのタスクが完了したらAとしてのコードレビューは不要だとしても動作検証は必要と思います。
Aでの動作が確認できたうえでfeatureにマージされるのがあるべき形ではないかと思っております。

往々にして、B,Cの改修をAにマージするとB単体では問題なかったがCの対応をマージすることで想定と違った動きになってしまう、などがあると思っていますので。

ブランチの切り方などは文化の違いで大きく変わってくると思いますので、検討違いなことを言っていたら申し訳ないです。

「いいね!」 1