使用git更新共享的分支存储库

如果我正确理解，您将拥有一个看起来像这样的（本地）存储库：

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

现在，A已更新，因此如下所示：

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

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

                          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。在这种情况下，您应该在提交消息中明确说明这些更改来自何处。