Githubで依存プル要求は可能ですか？
現在、私は本当に大きなプルリクエストに取り組んでいます。コードレビューを何らかの形で管理しやすくするために、アイデアは完全なプルリクエストを分離された部分に分割することでしたが、それらは互いに依存しています。
例は次のとおりです。
- プル要求1：インターフェースの作成：インターフェースAおよびBおよびコードの再構築
- プル要求2：インターフェースAの実装とテスト（プル要求1に依存）
- プルリクエスト：インターフェイスBの実装とテスト（プルリクエスト2に依存）
- プルリクエスト4：実装の混合テスト（2 + 3に依存）
Githubに、4つのプルリクエストすべてを同時に依存関係とともにファイルする方法はありますか？
私の知る限り、これは不可能であり、私の意見では、他のコードレビューツールと比較してGitHubの大きな欠点の1つです。相互に依存するコミットをプッシュすると、Gerritは自動的に依存コードレビューを設定します。Phabricatorでは、それは苦痛ですが、それでも可能です。
人々がGitHub PRを使用する方法は複数あることにも留意してください。通常のオープンソースコラボレーションの方法は、リポジトリを分岐してクロスリポジトリプルリクエストを送信することですが、他の場合（組織内など）では、同じリポジトリ内のすべての差分のプルリクエストを送信する場合があります。単一のリポジトリ内で、依存するプルリクエストのラインに沿って何かを取得する方が合理的だと思います。そのレポジトリ内にコミット/ブランチ構造を設定できるからです。
依存プル要求のいくつかの利点を得る方法を説明するブログ投稿は、すべてのコミットが同じリポジトリにあることが必要だと思います： http://graysonkoonce.com/stacked-pull-requests-keeping-github -diffs-small /
まとめ：
- 5つの依存するプルリクエストを送信するには、5レベルの深さのブランチ階層を作成し、前のブランチに基づいてそのブランチとして各PRを送信します。
- レビュー2/5を更新するには、更新をブランチ2にプッシュし、3つのマージ操作を実行して、変更をレビュー3、4、および5に統合します。
GitHubはPRのターゲットブランチの更新をサポートしていないため、すべての変更を一度に取得する必要があります。この例では、5つのコードレビューすべてが単一のコミットとして収集されました。GitHubはPRのベースブランチの更新をサポートするようになったため、PRは一度に1つずつ着陸できます。
そのアプローチは、小さな部分でレビューするのが最適な巨大な変更に対してはうまくいくようです（ただし、nレベルの深いブランチ階層を維持することは、git rebase -i）、ただし、レビューのさまざまな段階で依存する差分を持つことができ、レビューされた以前の差分を取得できる「コードレビューパイプライン」は実際には許可されません。
制限を呼び出していると思われるその他のインターネットリソース：
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があることを言及することができます。