現在、私は本当に大きなプルリクエストに取り組んでいます。コードレビューを何らかの形で管理しやすくするために、アイデアは完全なプルリクエストを分離された部分に分割することでしたが、それらは互いに依存しています。
例は次のとおりです。
Githubに、4つのプルリクエストすべてを同時に依存関係とともにファイルする方法はありますか?
私の知る限り、これは不可能であり、私の意見では、他のコードレビューツールと比較してGitHubの大きな欠点の1つです。相互に依存するコミットをプッシュすると、Gerritは自動的に依存コードレビューを設定します。Phabricatorでは、それは苦痛ですが、それでも可能です。
人々がGitHub PRを使用する方法は複数あることにも留意してください。通常のオープンソースコラボレーションの方法は、リポジトリを分岐してクロスリポジトリプルリクエストを送信することですが、他の場合(組織内など)では、同じリポジトリ内のすべての差分のプルリクエストを送信する場合があります。単一のリポジトリ内で、依存するプルリクエストのラインに沿って何かを取得する方が合理的だと思います。そのレポジトリ内にコミット/ブランチ構造を設定できるからです。
依存プル要求のいくつかの利点を得る方法を説明するブログ投稿は、すべてのコミットが同じリポジトリにあることが必要だと思います: http://graysonkoonce.com/stacked-pull-requests-keeping-github -diffs-small /
まとめ:
そのアプローチは、小さな部分でレビューするのが最適な巨大な変更に対してはうまくいくようです(ただし、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を使用する人々は一般的に、依存するコードレビューに依存しないようにワークフローを構築しようとするだけです。いくつかの例: