Github中是否存在依賴請求？

Question

目前我正在處理一個非常大的拉請求。爲了保持代碼審查以某種方式易於管理，這個想法是將孤立部分中的完整請求分開，然而這依賴於彼此。

一個例子是：

• 拉請求1：創建接口：接口甲& B和重組代碼
• 拉請求2：接口甲實施和測試（取決於拉request1 ）
• 拉請求3：接口B的實施和測試（取決於拉請求2）
• 拉要求4：實現混合測試（取決於2 + 3）

是否有在Github上的方式提交，同時具有依賴性的所有四個引入請求？

Answer 1

就我所見，這是不可能的，在我看來，這是GitHub與其他代碼審查工具相比的主要缺點之一。當你推動相互依賴的提交時，Gerrit會自動設置相關的代碼評審，而在Phabricator中，這更加痛苦，但仍然有可能。

記住人們使用GitHub PRs有多種方式也很好。正常的開源協作方式是分叉回購並提交交叉回購請求，但在其他情況下（例如在組織內），您可以在同一個存儲庫中提交差異請求。我認爲在單個存儲庫中，依賴於拉取請求的方式來獲取某些內容會更合理，因爲您可以在該存儲庫中設置提交/分支結構。

這裏有一個博客帖子，描述瞭如何獲得相關的引入請求，我認爲的一些優勢，就需要所有提交給在同一回購： http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/

摘要：

• 要提交5個依賴的pull請求，創建一個5級深度的分支層次結構，並根據前一個分支提交每個PR作爲該分支。
• 要更新第2條評論，共5條，請將更新推送到分支2，然後進行3次合併操作，以將更改集成到評論3,4和5.
• 您需要一次登錄所有更改，因爲GitHub不會不支持更新PR的目標分支。在這個例子中，所有5個代碼評論都是作爲一次提交而登陸的。

這種做法似乎工作確定爲最好在更小的碎片審查巨人的變化（雖然維持正級深分支層次結構是一種痛苦的東西，如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的永久居民的人一般只是嘗試構建自己的工作流程，不靠依賴代碼評論。一些示例：

• 不要將變更分解爲可獨立審查的增量步驟，而應將其作爲整體代碼審覈進行提交，以便一次登陸。 GitHub仍然允許您將代碼審查分成多個提交，審閱者可以查看，但他們不能獨立批准/登陸。
• 嘗試構建您的工作，以便在代碼的不相關部分進行更改，並將其放在可用於提交獨立PR的獨立分支上。您仍然可以使用櫻桃採摘或其他方法保留所有更改的本地分支。
• 如果您的更改取決於優秀的PR，只需等待PR接受併合並後再提交新的PR。你可能會提到某個地方，你有另一個PR取決於那個，也許這會激勵代碼審查人員更早到達那個。