Git從分支同步分支

Question

假設我已經從“ A”的舊標記創建了分支“ B”。 我對“ B”進行了一些更改，並向“ A”打開了一個拉回請求。 然后，我從“ B”創建一個“ C”分支，然后對其進行更改並打開拉取請求等，直到到達分支“ E”為止。

我完成對“ E”的更改后，可以說所有這些分支仍然具有針對“ A”的未合並合並的拉取請求。 由於這些內容可以按任何順序合並，並且“ E”可能已對我在“ B”中的原始更改進行了一些重要更改，因此如何確保“ B”具有從“ C，D，E”開始的更改； “ C”具有與“ D，E”相比的更改； “ D”具有與“ E”相比的更改。

假設我需要返回並在合並任何拉取請求之前對A進行更改，但是它依賴於E中的某些更改。

A -----
 \
  B -----
   \
    C -----
     \
      D -----
       \
        E -----

Answer 1

繪制方式， C具有所有B加一些， D具有所有C加一些，並且E具有所有D加一些，因此，當將E合並為A ，會將D ， C和B合並為A ，所以A將擁有全部。

如果您說可以按任何順序合並B ， C ， D或E中的任何一個，並詢問“ Git如何知道每次合並什么提交”？ 好吧，這是git merge的重要思想之一-git會回過頭來意識到已經被合並的內容，並且不會嘗試重新合並這些更改。 舉例來說，如果合並B ，它是由B1 ， B2和B3 ，然后合並C （其由C1 ， C2 ， C3 + B （ B1 ， B2 ， B3 ）），然后GIT中着眼於合並歷史並找到從合並點已經到達的所有提交，找到未到達的提交，然后合並那些無法到達的提交，這就是它知道要合並的內容（在這種情況下，它將是C1 ， C2 ， C3因為發現B1 ， B2 ， B3可達）。 因此，在內部，例如，如果您已經將B合並為A ，然后告訴它將C合並為A ，則git通過執行git rev-list C --not A類的操作來標識未合並的提交，然后合並這些提交。理解這一點的關鍵是像一個圖一樣思考它，並意識到git只是試圖從合並點和要合並的分支中找出該圖的哪些部分是不可達的，而這些是它隨后想要的更改合並。

如果您在合並B之后繼續使用B （使用B4 ），那很好，您可以簡單地重新合並分支B ，它將只接受從B到A的新更改，因為它執行了我剛剛描述的圖遍歷並意識到B1 ， B2和B3已經合並，現在只是它需要合並的這個新B4 。

Answer 2

從父分支創建的分支的典型生命周期是，前者最終會在某個時候合並回到父中。 這個概念不僅限於Git，還包括一般的開發流程。

在您的情況下，如果遵循此原則，它將立即解決您的問題。 這是您的圖表，重新繪制后變得更加可口：

A -----
 \
  B -----
   \
    C -----
     \
      D -----
       \
        E -----

按照將分支合並回其父代的原則，合並的順序應為E到D ， D到C ， C到B ，最后是B到A 在這些合並中的每一個中，理想情況下都應該沒有沖突。 如果有沖突，他們不應該由於母公司和分公司踩着對方的腳趾，即在功能完全相同的領域工作過兩個分支。

如果您的開發過程可能需要先將 E中的更改引入A中，然后再匯總它們之間的所有分支，那么您應該重新考慮如何創建分支。 在這種情況下，最好直接從父分支創建分支A到E