使用git更新共享分叉存储库

Question

考虑存储库一个通过Gerrit管理的github存储库。 我克隆了存储库A，并且我从存储库A的主分支开始创建了一个新分支。我将这个新分支放在一个新的gitlab存储库B上。我是存储库B上的管理员，并且我与其他开发人员共享了它。开发人员不能推动这个分支，但我可以合并他们的pull请求。 我在存储库B的master分支上合并了一些pull请求。因此，存储库B具有存储库A的初始提交和提交请求的新提交：B在A提交（b a）之上提交。

然后，我想用存储库A的新提交来更新存储库B.调用这些提交a +。

我看到两个选项：

1. 如果我合并甲对乙，结果是：A + B一个。
2. 如果我在A +上对B进行rebase，结果为：b a + a。

选项1：开发提交与外部提交混合。难以调试和突出差异。

选项2：我必须推动远程B上的更改。如果我没有弄错，后果可能是： 1.如果开发人员拉B并且他们已经提交B的本地主人，他们将失去他们的地方变化; 2.开发商在强制更新分公司B后，可能会面临重组其他分支机构时遇到的麻烦。

我应该如何避免出现任何问题？

Answer 1

如果我理解正确的话，你有一个单一的（本地）仓库看起来有点像这样：

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

现在，A被更新，所以它看起来是这样的：

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

请注意，您有两条不在一条直线上的分支。所以说当你合并A到B是不正确的，你会得到a+ b a。你得到一个合并，但保持了历史，因为它是：

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

正如你所看到的，你仍然有在提交来自的信息：a和a+之间的那些从一个分支来了， a和b之间的其他值来自另一个。并且M结合了这些tro分支。通常，这个正是解决这个问题的正确方法。

这个优于基准的好处 - 就像你注意到自己 - 是提交保持它们的样子。所有与这两个存储库交互的用户都可以简单地在没有任何问题的情况下进行这些更改。如果你重新提交了这些提交，他们将不得不手动修复（有可能他们甚至没有意识到这一点，所以他们只会拉，实际上创造一个更复杂的提交历史重复）。

所以合并肯定更适合在这里工作。是的，历史看起来不像一条直线那样完美，但它恰当地表达了发生的事情：有一条分离的开发线，它是独立的，然后随着来自上游存储库A的更改而更新。这些信息可能很有用，因此保持它们是有意义的。特别是如果您有用户与这两个遥控器进行交互，他们肯定会更喜欢保持其存储库与两个遥控器兼容。

如果不希望历史不要到这个样子，不与A关心的兼容性，您还可以壁球都是从A更改到您的B：

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

这里，[A]是一个压扁的提交，它包含在单个提交中的所有a和a+之间的更改。您可以通过将A重新指定为B来获得此结果，同时压缩所有提交。在这种情况下，您应该明确指出这些更改来自提交消息的来源。