我可能會開始為一個開源專案處理拉取請求。添加的大部分代碼將獨立于專案的其余部分，主要是 CMake 檔案，以幫助構建主專案的變體。在我最初的作業計劃中，我已經確定需要對主要來源進行一些更改，主要是洗掉不需要的遺留代碼，這會妨礙我的其余作業。由于這些更改通常用于整理專案，因此我希望能夠獨立于整體拉取請求提交它們。
由于我不是維護者，我將分叉主倉庫，并創建一個跨倉庫拉取請求。我預計會為主要更改創建一個 PR 草案，并準備好合并那些整理提交的 PR。
無法保證維護人員將合并子拉取請求，直到他們看到其余作業的結果，但我不希望他們在長期運行的分支的所有其他提交中迷失方向。
我假設我可以向我的單體分支添加提交，當我發現除了其他所有內容之外有用的更改時，我可以從 master 創建一個新分支，挑選必要的提交，然后創建一個拉取請求那個子分支。
當維護者合并任何子 PR 和/或整體 PR 時會發生什么，如果在我的單體 PR 之前合并部分/所有子 PR 時我從 master 變基，我的本地會發生什么PR 作為最終提交？
Master -> A -> B -> C -> D
|
|-> Monolithic-Branch -> E -> F -> G -> H -> Rebase Master -> Submit as final
|
|-> SubBranchA -> Cherry E
|
|-> SubBranchB -> Cherry F & G
uj5u.com熱心網友回復：
當維護者合并任何子 PR 和/或整體 PR 時會發生什么，如果在我的單體 PR 之前合并部分/所有子 PR 時我從 master 變基，我的本地會發生什么PR 作為最終提交？
當維護者合并您的子 PR 時，您將需要Monolithinc-Branch在更新的master分支上重新設定您的基礎。這將消除您的功能分支中的一些提交（并且根據您的更改的性質，可能需要解決一些合并沖突）。
如果您Monolithic-Branch在子 PR 之前合并，則可以丟棄子 PR，因為更改已經合并到您的功能分支中。
最后，如果您有時間并且對替代作業流程感興趣，我建議您查看stacked git，我發現它對于管理這種情況（您有一堆依賴提交）非常有用。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/515222.html
標籤：混帐github拉取请求