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' 分支中更新 'feature1' 分支中的更改，然后再更新我对它的更改。

有什么方法可以用 GIT 命令做到这一点？

Answer 1

在本地仓库中将 feature1 变基为 develop。它将回退 feature1 中的任何更改，将 develop 合并到 feature1，然后重做您的更改。

git checkout feature1

git rebase develop

将您的本地仓库强制推送到您的主仓库。

git push -f

将您的分支（例如，feature2）重新设置为 feature1。

git checkout feature2

git rebase feature1

参考：https://git-scm.com/book/en/v2/Git-Branching-Rebasing

希望对您有所帮助！

编辑：阅读，因为这会使其他开发者的本地仓库有些损坏。

Answer 2

根据我收集到的信息，这是您存储库中的情况：

                  develop
                    ↓
A -- A -- B -- C -- C
           \
            F -- F -- F
                      ↑
                   feature1

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

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

在那种情况下，假设您与用户 1 不是同一个开发人员，将这些更改引入功能分支的最安全方法是简单地合并它们。因此，虽然有 feature1 签出，只需使用 `git merge develop* 合并 develop。然后，历史将如下所示：

                      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

当然，这让历史看起来有些混乱，但它正确地代表了功能分支如何随着时间的推移而演变，而相关的变化仍在 develop.

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

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

                  develop
                     ↓
A -- A -- B -- C1 -- C2
           \
            F -- F -- F -- C1'
                            ↑
                        feature1

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

最后，剩下的选择是变基。变基重写历史，因此再次从第一张图开始，您可以通过运行ning git rebase develop:

得到以下结果

                 develop
                    ↓
A -- A -- B -- C -- C
                     \
                      F' -- F' -- F'
                                  ↑
                               feature1

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

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

因此，除非您知道自己在做什么，否则您应该永远不要变基之前已发布的提交。即使这意味着您的历史记录会因此变得不那么好看。

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

Git update my remote branch from another remote branch

git

github

master

git-merge

git-branch