Git 从另一个远程分支更新我的远程分支

Question

我们有一个名为“develop”的主分支，所以每当我们开发一个功能时，我们都会从“develop”创建一个本地功能分支，然后再合并回开发。

现在的情况是，
1. User1 必须从“develop”（比如 feature1）创建一个功能分支，并且他必须将其发布到 Git。这个做完了。
所以现在，“develop”和“feature1”是 Git 中的 2 个不同分支，“feature1”中的更改不会合并到“develop”，因为“feature1”仍在开发中。
2. 后来我开始实现的功能对'feature1'有一些依赖。所以我从 git 克隆了 'feature1' 分支并决定更新我对它的更改，认为 'feature1' 已经从 'develop' 分支更新。
3.但后来我发现'feature1'分支没有更新'develop'分支的一些最新变化。
4.现在我需要'develop'的改变

使用 GIT 命令有什么可能的方法吗？

Answer 1

从我收集的信息来看，这是您存储库中的情况：

                  develop
                    ?
A -- A -- B -- C -- C
           \
            F -- F -- F
                      ?
                   feature1

因此，提交A是对之前存在的开发的提交。B是在创建功能分支时开发的基础提交。F是在功能分支上C进行的提交，是在功能分支已经创建并正在处理之后在开发上进行的提交。

现在，您要做的是继续在功能分支上工作，同时取决于 commits 引入的更改C。那正确吗？

在这种情况下，假设你是不一样的开发者为用户1，引进这些变化为特征的分支是简单地将它们合并的最安全的方式。因此，虽然具有特征1签出，只是合并开发使用`git的合并发展*。然后，历史将如下所示：

                      develop
                         ?
A -- A -- B ---- C ----- C
           \              \
            F -- F -- F -- M
                           ?
                        feature1

因此，您只需合并更改，然后您就可以继续对其进行处理。事实上，随着feature1和develop 的增长，您可以继续多次这样做：

                                     develop
                                        ?
A -- A -- B ---- C ----- C -- C -- C -- C
           \              \         \    \
            F -- F -- F -- M -- F -- M -- M -- F
                                               ?
                                            feature1

一旦你完成了功能分支，你就可以将它合并到develop 中：

                                              develop
                                                 ?
A -- A -- B ---- C ----- C -- C -- C -- C ------ M
           \              \         \    \      /
            F -- F -- F -- M -- F -- M -- M -- F

当然，这使历史看起来有点凌乱，但它代表了正确的特性分支是如何随着时间而演变，而相关的变化仍然在发生发展。

如果你想避免这样的历史，有几个选择。如果您只依赖很少的更改，例如在单个提交中引入的一些更改而其他提交与您无关，您也可以将那个提交挑选到功能分支上。Cherry-picking 允许您复制提交，本质上是完全重用它，同时仍将其作为单独的提交。

比方说，您只需要C上面显示的第一个图表中的第一个提交。然后你可以git cherry-pick C1把它复制到功能分支：

                  develop
                     ?
A -- A -- B -- C1 -- C2
           \
            F -- F -- F -- C1'
                            ?
                        feature1

这将创建一个副本C1'，其中包含与其原始更改相同的更改C1（但仍然是不同的提交对象）。然后，您可以继续在包含这些更改的功能分支上工作。

最后，剩下的选择将是变基。变基会重写历史记录，因此再次从第一个图开始，您可以通过运行以下命令结束git rebase develop：

                 develop
                    ?
A -- A -- B -- C -- C
                     \
                      F' -- F' -- F'
                                  ?
                               feature1

需要记住的重要一点是，历史确实被重写了，因此feature1上的所有提交都被修改和重新创建。这导致它们成为具有不同提交标识符的完全不同的对象，从而使它们与分支的先前状态不兼容。

这会导致其他开发人员，在您的情况下，尤其是在feature1分支上工作的“用户 1”，当他们尝试合并您的更改时遇到冲突。修复这将需要他们手动修复它，除非您告诉他们，否则他们甚至可能不会注意到（使历史变得非常混乱并因此而有些破碎）。

因此，除非您知道自己在做什么，否则永远不要对之前已发布的提交进行变基。即使这意味着你的历史结果看起来会不那么好。