我對 GitHub 不太熟悉，但我有一個功能分支，我想多次將其當前更改合并到 master。理想情況下，我想分解拉取請求，這樣一個 pr 就不會太長。例如，我首先需要一個前端的 pr。合并后，我將推送后端的更改并創建另一個 pr。我想確保同一個功能分支可以有多個 prs 來掌握（但只會有一個打開的 pr）。
Github 允許這樣做嗎？
uj5u.com熱心網友回復：
@aspiringsomeone，保持每個 PR 增量、獨立和簡潔是一個很好的策略。但是，最好為新的一組更改（功能）創建一個新分支。在 GIT 中，分支只是標記，不會消耗太多空間/資源。合并 PR 后，您可以洗掉該分支并為下一個 PR 創建一個新分支。
在您的情況下，第一個分支可能是 feature1_frontend （希望這些更改不依賴于后端或以某種方式禁用，直到后端更改準備就緒）。PR_1 合并后，您可以創建 feature1_backend 分支并將其用于下一個 PR，例如 PR_2。當 PR 審查完成并合并后，您可以洗掉相應的分支并繼續。
uj5u.com熱心網友回復：
理想情況下，拉取請求應該是獨立的。
千萬不能保持手頭長壽命特性分支，并保持它合并（同一分支）。這是結束無數合并沖突的好方法。您應該始終在合并后立即洗掉 PR 分支。
不過別擔心。如果一個拉取請求必須依賴于另一個，那么有一種更好的方法：在 GitHub 中，您實際上可以打開多個源自彼此的 PR，這可能是這里進行的方式。所以：
從你的主分支分支形成
feature1并推送它并打開一個 PR 要求合并到主分支。分支
feature1到表單feature2并推送它并打開一個 PR 要求合并到feature1.分支
feature2到表單feature3并推送它并打開一個 PR 要求合并到feature2.
這是很酷的部分。當feature1批準并合并到主分支時，GitHub 將自動重新設定feature2PR，以便它現在要求合并到主分支，這正是您想要的。等等。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/395084.html