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

Update shared forked repository using git

将存储库 A 视为通过 Gerrit 管理的 github 存储库。 我克隆了存储库 A,并从存储库 A 的主分支开始创建了一个新分支。我将这个新分支推送到新的 gitlab 存储库 B。我是存储库 B 的管理员,我与其他开发人员共享了它。开发人员无法在该分支上推送,但我可以合并他们的拉取请求。 我在存储库 B 的主分支上合并了一些拉取请求。因此,存储库 B 具有存储库 A 的初始提交和拉取请求的新提交:B 提交在 A 提交之上 (b a)。

然后,我想用存储库 A 的新提交更新存储库 B。 将这些提交称为 a+。

我看到两个选项:

  1. 如果我在B上合并A,结果是:a+ b a。
  2. 如果我将 B 变基到 A+,结果是:b a+ a。

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

选项 2:我必须强制远程 B 上的更改。如果我没记错的话,结果可能是: 1. 如果开发人员拉取 B 并且他们在 B 的本地 master 上提交,他们将丢失本地更改; 2. 分支B被强制更新后,开发者在rebase本地分支时可能会遇到很大的麻烦

我应该如何操作才能避免出现问题?

如果我理解正确的话,你有一个单一的(本地)存储库,看起来有点像这样:

            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

如您所见,您仍然拥有提交来源的信息:aa+ 之间的那些来自一个分支,而其他 a 之间的b 来自另一个。 M 结合了那些 tro 分支。通常,这个正是解决这个问题的正确方法。

与变基相比的好处——正如您自己注意到的那样——是提交保持原样。与任一存储库交互的所有用户都可以毫无问题地轻松拉取这些更改。如果您重新定位这些提交中的任何一个,他们将不得不手动修复它(很可能他们甚至没有意识到这一点,所以他们只会拉取并实际创建一个带有重复提交的更混乱的历史记录)。

所以在这里使用合并绝对更好。是的,历史看起来不像直线那么完美,但它正确地传达了发生的事情:有一条独立的分叉开发线,然后随着上游存储库 A 的更改而更新。此信息可能很有用,因此将它们保留在其中是有意义的。特别是如果您有用户与这两个遥控器进行交互,他们肯定更愿意保持他们的存储库与两个遥控器兼容。

如果您不希望历史看起来像这样,并且不关心与 A 的兼容性,您也可以将 A 中的所有更改压缩到您的 [=17] =]:

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

在这里,[A] 是一个压缩的提交,它在单个提交中包含了 aa+ 之间的所有更改。您可以通过在压缩所有提交时将 A 变基到 B 来获得此结果。在这种情况下,您应该在提交消息中清楚地说明这些更改的来源。