2016-09-19 52 views
14

考慮存儲庫一個通過Gerrit管理的github存儲庫。 我克隆了存儲庫A,並且我從存儲庫A的主分支開始創建了一個新分支。我將這個新分支放在一個新的gitlab存儲庫B上。我是存儲庫B上的管理員,並且我與其他開發人員共享了它。開發人員不能推動這個分支,但我可以合併他們的pull請求。 我在存儲庫B的master分支上合併了一些pull請求。因此,存儲庫B具有存儲庫A的初始提交和提交請求的新提交:B在A提交(b a)之上提交。使用git更新共享分叉存儲庫

然後,我想用存儲庫A的新提交來更新存儲庫B.調用這些提交a +。

我看到兩個選項:

  1. 如果我合併甲對乙,結果是:A + B一個。
  2. 如果我在A +上對B進行rebase,結果爲:b a + a。

選項1:開發提交與外部提交混合。難以調試和突出差異。

選項2:我必須推動遠程B上的更改。如果我沒有弄錯,後果可能是: 1.如果開發人員拉B並且他們已經提交B的本地主人,他們將失去他們的地方變化; 2.開發商在強制更新分公司B後,可能會面臨重組其他分支機構時遇到的麻煩。

我應該如何避免出現任何問題?

回答

7

如果我理解正確的話,你有一個單一的(本地)倉庫看起來有點像這樣:

  A/master 
       ↓ 
* -- * -- * -- a 
       \ 
       * -- * -- b 
          ↑ 
         B/mybranch 

現在,A被更新,所以它看起來是這樣的:

      A/master 
           ↓ 
* -- * -- * -- a -- * -- * -- a+ 
       \ 
       * -- * -- b 
          ↑ 
         B/mybranch 

請注意,您有兩條不在一條直線上的分支。所以說當你合併AB是不正確的,你會得到a+ b a。你得到一個合併,但保持了歷史,因爲它是:

      A/master 
           ↓ 
* -- * -- * -- a -- * -- * -- a+ 
       \    \ 
       * -- * -- b --- M 
           ↑ 
          B/mybranch 

正如你所看到的,你仍然有在提交來自的信息:aa+之間的那些從一個分支來了, ab之間的其他值來自另一個。並且M結合了這些tro分支。通常,這個正是解決這個問題的正確方法。

這個優於基準的好處 - 就像你注意到自己 - 是提交保持它們的樣子。所有與這兩個存儲庫交互的用戶都可以簡單地在沒有任何問題的情況下進行這些更改。如果你重新提交了這些提交,他們將不得不手動修復(有可能他們甚至沒有意識到這一點,所以他們只會拉,實際上創造一個更復雜的提交歷史重複)。

所以合併肯定更適合在這裏工作。是的,歷史看起來不像一條直線那樣完美,但它恰當地表達了發生的事情:有一條分離的開發線,它是獨立的,然後隨着來自上游存儲庫A的更改而更新。這些信息可能很有用,因此保持它們是有意義的。特別是如果您有用戶與這兩個遙控器進行交互,他們肯定會更喜歡保持其存儲庫與兩個遙控器兼容。

如果不希望歷史不要到這個樣子,不與A關心的兼容性,您還可以壁球都是從A更改到您的B

      A/master 
           ↓ 
* -- * -- * -- a -- * -- * -- a+ 
       \ 
       * -- * -- b -- [A] 
           ↑ 
          B/mybranch 

這裏,[A]是一個壓扁的提交,它包含在單個提交中的所有aa+之間的更改。您可以通過將A重新指定爲B來獲得此結果,同時壓縮所有提交。在這種情況下,您應該明確指出這些更改來自提交消息的來源。