Question

带有Git的版本控制有一个示例

至将特征分支上的P和Q提交从maint移植到master 分支，发出命令：
 $ git rebase --onto master maint^ feature

下面的命令是否也给出相同的结果

git rebase --onto master maint feature

？

这本书为什么使用maint^而不是maint？

谢谢。

Answer 1

由于时间紧迫，我只想在这里简短回答：

下面的命令是否也给出相同的结果
git rebase --onto master maint feature
？

对于此特定图形，是的。对于（某些）其他图形，不。（当然，对于其他图形，他们可能会建议其他命令。）

这本书为什么使用maint^而不是maint？

不是作者，我只能猜测。 git rebase的这种特定形式与the SYNOPSIS section of the git rebase documentation中的第一种语法匹配：

 git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
         [<upstream> [<branch>]]

在这里，他们设置 newbase = master， upstream = maint^和 { {1}} = branch。因此，这将首先进行feature，然后枚举git checkout feature中的提交以查找要复制的候选对象。如果查阅您的图，您将看到这恰好是maint^..HEAD和P：它从Q开始，回到Q，从那里到达{{ 1}}和P 是 Y。

使用Y，Git将从maint^开始，回到git rebase --onto master maint feature，回到Q，然后仍然停止-因为P标识为{ {1}}，然后从Y返回，将我们带到maint。但这需要从Z返回的额外步骤。大概作者不愿强迫读者在读者的脑海中采取额外的步骤。

Answer 2

git rebase的三个参数形式–onto 假设某个分支“ topicA”在某些时候与母版有所不同：

A--B--C--D--E主控

 F--G--H topicA

我们也说其他人已经从topicA分支到创建topicB，并添加了更多提交：

A--B--C--D--E主控

 F--G--H topicA

         I--J--K--L--M topicB

这是我遇到的一个真实案例的示例，其中topicA仅具有几个非常难以理解的非常大的提交，并且可能被拆分为许多较小的提交。 topicB的创建是对topicA所做工作的延续。

我签出了自己的本地topicA副本，并通过大量的交互基础和git add -e的大量使用，我能够将topicA拆分为较小的提交，从而生成topicC：

我与制作topicA的人进行了交谈，我们同意我的分支topicC应该代替topicA。但是对topicB所做的工作该怎么办？

我们要执行的操作是：使topicC成为topicB的新基础，将其切入到topicB与topicA背离的位置，如下所示：

A--B--C--D--E主 | | F--G--H主题 | | I--J--K--L--M主题B

 N--O--P--Q--R--S--T--U--V--W--I'--J'--K'--L'--M' topicC

topicB的五次提交（从I到M），从topicB与topicA分开的地方开始，在topicC的顶部播放，以创建I'，J'，K'，L'和M'。

执行此操作的命令是：

git rebase --onto topicC topicA topicB

topicC是新库，topicA是旧库，topicB是topicC的HEAD的引用。

所以您的答案是，是的，可以不使用^

^的含义是：

HEAD ^表示当前分支的尖端的第一个父代。

请记住，git commit可以有多个父级。 HEAD ^是HEAD ^ 1的缩写，您也可以根据需要寻址HEAD ^ 2等。

您可以联系任何提交的父母，而不仅仅是HEAD。您还可以世代相传：例如，master〜2表示master分支的顶端的祖父母，在模棱两可的情况下偏向于第一父级。这些说明符可以任意链接，例如，topic〜3 ^ 2。

我如何理解这个git rebase --onto示例？

2 个答案: