我有一個需要幫助的作業流程。我通常創建一個分支并在 github 上打開一個拉取請求（標準程式）。但是，有時我想創建另一個 PR，該 PR 依賴于先前仍處于打開狀態的 PR。我想在第一個 PR 仍然開放時對第二個 PR 進行評論。
為此，我首先創建另一個分支（從較早的分支中分離出來）并打開一個請求更改到第一個分支的 PR。同時，如果我對第一個分支進行了更改（針對第一個 PR 的評論），我會將它們提交到第一個分支，然后將它們變基到第二個分支。然后我強制將第一個分支和第二個分支推送到他們的遙控器。
但是，問題是第二個 PR 有時會顯示第一個分支的更改。這是一個線性的歷史，我認為 github 很困惑。我嘗試了這個奇怪的事情，我將第二個 PR 中的分支更改為其他一些共同的祖先分支，然后將其更改回第一個分支，突然之間不應該出現的第一個分支的更改消失了。
有沒有辦法防止這個問題發生？我從不希望第一個 PR 的更改出現在第二個 PR 中（作為提交）。我只是想讓第二個 PR 看起來像是在向第一個 PR 提交更改。
在第一個 PR 合并后，我通常會進入第二個分支rebase --onto our_main_branch并更新 github 中的第二個 PR 以請求將更改合并到our_main_branch. 我也歡迎對更好的作業流程提出任何意見。
uj5u.com熱心網友回復：
不，而且沒有意義
我聽到你在說什么，但你必須從上游回購的角度來看待它。他們還沒有接受你的第一個 PR。您的第二個 PR 包括您的第一個 PR。由于 GitHub PR 是獨立的（不支持 PR 依賴項，即一種說法：“此 PR 要求您首先接受另一個PR），上游 repo 必須能夠接受第二個 PR，并為此有道理，它必須包括第二個 PR 所依賴的所有提交。
不過沒關系
只需在您的第二個 PR 中明確說明它是您在描述中的第一個 PR 的超集。您可以要求他們的 repo 所有者按順序接受它們，但他們也可以只接受您的第二個 PR，因為它包括兩組更改。
也可以看看：
- 你如何處理 Github 中舊拉取請求的新依賴？
- 處理順序拉取請求之間依賴關系的好策略
uj5u.com熱心網友回復：
實際上，GitHub 很好地應對了這種情況。您只需要確保第二個 PR 在第一個 PR 之前不會被接受。
因此，假設您在main. 因此，main您創建一個分支feature1并推送它并要求將 PR合并到main. 然后，你要繼續作業，所以你讓一個分支feature2 關閉的feature1，當你完成時，有兩種可能性：
與此同時，
feature1PR獲得批準并合并。在這種情況下，拉動main并變基feature2到main，然后推動feature2并要求將 PR合并到main.好的，現在讓我們假設它
feature1仍在等待批準。聽起來很糟糕，嗯？但是沒問題！feature2無論如何，只需推動，并要求將 PR合并到feature1. 它看起來就像你想要的那樣！——這是精彩的部分。如果feature1現在被接受并合并，PR 將自動更改為合并到main，這就是您一直想要的。它仍然會像你想要的那樣看起來。基本上 GitHub 已經在幕后為您完成了 rebase。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/372634.html