为什么我的"git rebase master"返回的提交比上次合并后返回的"normal"多？

Question

我试图理解我做错了什么，但什么都没有。我完全糊涂了。 我知道合并分支(或提交)的另一种方法是使用"git rebase"。 我有 3 个分支：master 和另外 2 个用于不同功能的分支。让我们谈谈大师，f1和f2。 我正在开发我的 f1，我需要另一个功能，所以我创建了 f2。 当我完成 F1 时，师父已经有了另一个变化。我想在主节点上重定 f1 的基数。我做到了，我看到了144步。我尝试修复所有提交并推送更改。现在我将我的 f2 提交应用于 f1，并决定对 master 执行拉取请求。我尝试在主服务器上重新设置 f1，我得到了 244 步。或者它只是 master 上的 4 个新提交。我已经在我当地的主人身上得到了它们。

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

我必须告诉大家，一开始我只是用"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从命令中给出的基础开始进行 NEW 提交(在这种情况下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.说真的，这是处理它的最快方法。使用git merge master更新功能分支master，然后将功能分支merge回主分支(如果适用)。

或者，您可以深入研究交互式变基的黑魔法。运行git rebase时使用-i标志，您将看到它尝试重新应用的所有提交的列表。删除重复项，继续你的快乐之路。我不喜欢这种方法，因为它很容易犯错误，而且从这些错误中恢复是一个 PIA。

如何避免这种情况

详细文章

简而言之，您需要告诉 git 忽略重复的提交。使用rebase更新feature1很好，问题发生在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}- 我们只是rebasefeature1，所以我们需要获取上一个提交(即变基之前的提交)。这是我们正在移动的提交范围的开始
• feature2- 这是我们正在移动的提交范围的结束

注意：当用作本文中所述过程的一部分时，feature1@{1}将起作用，但如果在更新feature1和feature2之间运行其他 git 命令，则可能不正确。在这种情况下，您可以将其替换为原始提交 ID - 通过在feature2上查看git log的输出并从feature1中选择最后一个提交(此处给出的示例中为"C")获得。

其他好读物：

• 阿特拉斯文章：合并与变基

• 你什么时候使用 Git 变基而不是 Git 合并？