我可以發送分支B的拉取請求嗎?會有副作用嗎?
讓我們畫一個快速的畫面
X --- X --- X --- X <--(master)
\
A1 -- A2 <--(A)
\
B1 -- B2 -- B3 <--(B)
我承擔A
公關依然突出,所以A1
是master
和B
之間的差異。如果B
中沒有任何內容依賴於A1
,那麼這在概念上並不好;您不希望B
的批准/合併取決於接受/潛在的A1
過早發佈的變更。
現在,如果公關A
獲得批准,那麼合併後A1
不再是一個區別;你可以說「沒有傷害,沒有犯規」;但如果獨立分支機構獨立於master
之後,仍然最好。
我可以改爲在最後一次主合併時重新提交提交,並將提交重命名爲分支B上更改的名稱?這是否也會刪除我發送拉請求的分支A上的提交?
以第一部分爲準:rebasing不會刪除回購的提交;這是一個(看似普遍的)誤解。因爲A1
可從分支A
到達,所以它不會受到B
的重設影響。 但是,在重新綁定時應該小心,以避免創建一個重複的提交,因爲這會破壞rebase的目的。
git rebase --onto master A B
應該給你
B1' -- B2' -- B3' <--(B)
/
X --- X --- X --- X <--(master)
\
A1 -- A2 <--(A)
\
B1 --- B2 --- B3
(請注意,我已經展示了B1
,B2
,這對於圖清晰度B3
加強這一基礎重建不會刪除提交點。由於沒有如果你不知道如何尋找它們,你就不會看到它們,並且它們將被排除在push
之外,最終它們可能會被垃圾收集,但是在rebase之後,在你的本地回購你可以做一些像0123一樣的東西請注意,如果B
曾經被推送過,這可能會給其他開發者帶來問題(因爲雖然沒有提交從repo中移除,但是這確實會提交曾經是的提交B
可達不再可達來自B
,這並不好。
請參閱git rebase
文檔中的「從上游rebase」恢復,如果這看起來沒有問題,那麼您可以rebase。請記住,您需要重新測試已重建的B
,因爲它的樹處於一個獨特的新狀態。 (IMO的最佳做法是重新測試中間提交。)
如果我在接受請求之前需要對分支A進行其他更改,我還可以重新分割/壓扁分支A的提交嗎?影響分支B?
這個問題至少有幾個變化。
如果你有不重建基礎B
從A
遠,那麼任何墊底的操作,將改寫或更換A1
可能讓你在一個意想不到的狀態,因爲B
仍然將指向通過A1
(不A1'
這是在重訂創建,或在南瓜的情況下爲A1A2
,或其他)。
如果有重建基礎B
遠離A
,那麼你可以做任何你喜歡A
沒有進一步影響B
。再次,只要意識到重寫已推動歷史的風險。