[解決済み] Githubで依存性のあるプルリクエストは可能か？

質問

現在、私は非常に大きなプルリクエストに取り組んでいます。コードレビューを何とか管理しやすくするために、アイデアは、完全なプルリクエストを分離した部分に分割することでしたが、それらは互いに依存しています。

たとえば、次のようなものです。

• プルリクエスト1 : インターフェースを作成する。インターフェイス A と B を作成し、コードを再構築しました。
• プルリクエスト2 : インターフェースAの実装とテスト(pull request1に依存)
• プルリクエスト3 : インターフェースBの実装とテスト(pull request2に依存)
• プルリクエスト4 : 実装の混合テスト(2 + 3に依存)

Githubで、4つのプルリクエストを依存関係も含めて同時にファイルする方法はありますか？

どのように解決するのですか？

私が見る限り、これは不可能です。私の意見では、これは他のコードレビューツールと比較してGitHubの大きな欠点の一つです。Gerrit は互いに依存するコミットをプッシュすると、自動的に依存するコードレビューをセットアップします。Phabricator では、もっと面倒ですが、それでも可能です。

また、GitHubのPRには様々な使い方があることも覚えておくとよいでしょう。通常のオープンソースコラボレーションでは、リポジトリをフォークしてクロスレポプルリクエストを提出しますが、他のケース（例えば、組織内）では、同じリポジトリ内のすべての差分に対してプルリクエストを提出することもあります。私は、単一のリポジトリ内では、そのリポジトリ内でコミット/ブランチ構造を設定できるので、依存プルリクエストの線に沿って何かを得ることがより合理的であると思います。

すべてのコミットが同じリポジトリにあることが必要だと思いますが、従属プルリクエストの利点を得る方法を説明したブログ記事を紹介します。 http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/

要約です。

• 5つの依存したプルリクエストを提出するには、5レベルの深さのブランチ階層を作成し、各PRを前のブランチを基にしたそのブランチとして提出します。
• 5 つのレビューのうち 2 つを更新するには、ブランチ 2 に更新をプッシュし、3 つのマージ操作を行い、レビュー 3、4、5 に変更を統合します。
• GitHub は PR のベースブランチの更新をサポートするようになったので、PR を一度にひとつずつ着地させることができます。

このアプローチは、小さな断片でレビューするのが最適な巨大な変更に対しては問題なく機能するようです (ただし、n レベルの深いブランチ階層を維持することは、次のようなものに比べて苦痛です)。 git rebase -i

この方法は、巨大な変更に対して小分けにしてレビューするのは良いのですが (ただし、n レベルの深いブランチ階層を維持するのは のようなものと比べて苦痛です)、異なるレビュー段階において依存する diff を持ち、それらがレビューされるときに以前のものを着陸できるような "code review pipeline" には本当に適していません。

他のいくつかのインターネットリソースでも、この制限を呼びかけているようです。

https://www.quora.com/Is-there-a-good-system-for-adding-multiple-pull-requests-to-GitHub

https://muffinresearch.co.uk/how-do-you-deal-with-dependent-branches-on-github/

私の理解では、GitHub PRを使う人々は一般的に、依存するコードレビューに頼らないようにワークフローを構成しようとするだけです。いくつかの例を挙げます。

• 変更を独立してレビューできる段階的なステップに分割する代わりに、一度に着地するモノリシックなコードレビューとして提出する。GitHub では、コードレビューを複数のコミットに分割してレビュアーが閲覧することはできますが、独立して承認/着地させることはできません。
• コードの関連性のない部分に変更を加え、それを独立したブランチに置いて、独立した PR を提出できるように作業を構成するようにしましょう。チェリーピックや他のアプローチを使って、すべての変更を適用したローカルブランチを維持することはできます。
• 未解決の PR に依存する変更がある場合、新しい PR を提出する前に、PR が受理されてマージされるのを待つだけでよいのです。そのPRに依存する別のPRがあることをどこかに書いておけば、コードレビュー担当者がそのPRに早くアクセスする動機付けになるかもしれません。