为什么我的“git rebase master”在最后一次合并后返回的提交比“正常”多？

Question

我试图理解我做错了什么，但什么也没有。我完全困惑了。 我知道合并分支（或提交）的另一种方法是使用“git rebase”。 我有 3 个分支：master 和另外 2 个用于不同功能的分支。我们来谈谈master、f1和f2。 我正在开发 f1，并且需要另一个功能，因此我创建了 f2。 当我完成f1时，master已经有了另一个变化。我想在 master 上重新建立 f1 的基础。我做到了，我看到了 144 个步骤。我尝试修复所有提交并推送更改。现在我将我的 f2 提交应用到 f1 并决定向 master 发出拉取请求。我尝试在 master 上重新设置 f1 的基准，并得到 244 步。或者这只是 master 上的 4 个新提交。我已经把它们交给了我当地的主人。

我很困惑。每次我想使用 rebase 时，似乎我都会得到更多真正完成提交的步骤。

我必须告诉你，一开始我只是用“git merge”进行合并，但我被要求用“git rebase”进行合并。

我尝试寻找为什么我的步骤太多，我再次按照教程进行操作，但我无法再次尝试修复超过 200 个步骤。这很无聊，需要时间。 您能向我解释一下并帮助解决这个问题吗？ 我不想现在解决这个问题，以后再得到300多个。 谢谢

Answer 1

这是对 rebase 作用的误解，我相信这就是造成这种非常令人沮丧的情况的原因。

可能发生了什么

假设您有以下情况（我相信就是您所描述的情况）。

master  o---o---o---o---o---o
                 \
feature1          A---B---C
                           \
feature2                    X---Y---Z

您已经完成了

feature1

的工作，但是 master 上有一些提交尚未通过

feature1

更改进行测试。因此，要更新

feature1

，请执行以下操作：

• git checkout feature1

• git rebase master

这会导致以下情况：

master  o---o---o---o---o---o
                 \           \
feature1          \           A'---B'---C'
                   \        
feature2            A---B---C---X---Y---Z

等等，什么？为什么有两份

A-B-C

！？

这就是

rebase

的作用。

Rebase

从命令中给定的基数开始进行新提交（在这种情况下是

master

）。

接下来可能发生什么

现在

feature1

已更新为

master

的最新版本，您需要更新

feature2

。因此，您遵循相同的过程：

• git checkout feature2

• git rebase feature1

这会导致以下情况：

master  o---o---o---o---o---o
                             \
feature1                      A'---B'---C'
                                         \        
feature2                                  A"---B"---C"---X---Y---Z

呃哦。

正如您所看到的，经过几次这样的循环后，您最终会陷入一个非常糟糕的境地，您必须解决只是一遍又一遍地应用相同更改的“冲突”。

如何解决目前的混乱局面

硬着头皮使用

merge

。说实话，这是最快的处理方法。使用

master

更新来自

git merge master

的功能分支，然后

merge

将功能分支返回主分支（在适当的情况下）。

或者，您可以深入研究交互式变基的黑暗魔法。运行

-i

时使用

git rebase

标志，您将看到它尝试重新应用的所有提交的列表。删除重复项并继续您的快乐之路。我不喜欢这种方法，因为它很容易犯错误，而且它是从这些错误中恢复的 PIA。

如何避免这种情况发生

详细文章

简而言之，你需要告诉 git 忽略重复的提交。使用

feature1

更新

rebase

没问题，问题发生在

feature2

。

• git checkout feature2

• git rebase --onto feature1 feature1@{1} feature2

这让我们受益匪浅

master  o---o---o---o---o---o
                             \
feature1                      A'---B'---C'
                                         \        
feature2                                  X'---Y'---Z'

正是我们想要的！

那么，这个命令是做什么的？

git rebase --onto feature1 feature1@{1} feature2

• --onto feature1

  - 我们将把这些提交移到分支上

  feature1

• feature1@{1}

  - 我们只是

  rebase

  'd

  feature1

  ，所以我们需要获取上一次提交（即变基之前的提交）。这是我们正在移动的提交范围的开始

• feature2

  - 这是我们正在移动的提交范围的末尾

注意：当用作本文中描述的过程的一部分时，

feature1@{1}

将起作用，但如果在更新

feature1

和

feature2

之间运行其他 git 命令，则可能不正确。在这种情况下，您可以将其替换为原始提交 ID - 通过在

git log

上查看

feature2

的输出并从

feature1

选择最后一次提交（此处给出的示例中的“C”）来获得。

其他好读物：

• Atlassian 文章：合并与变基

• 什么时候使用 Git rebase 而不是 Git merge？

Answer 2

如果您在

vscode

上合并，并且当您完成冲突后，如果按

vscode

左下角的同步按钮而不是执行 git push -u origin

branch-you-are-merging-to-master

，您可能会遇到此问题