为什么git rebase不显示我要压缩的提交？

Question

我正准备在我正在研究的分支机构上发起拉取请求.在github上,我看到我提前完成了5次提交,所以我想将我的提交压缩成一个.我运行一个git日志来查看以前的提交是什么:

git log --oneline

4363273 Updated Order_Entry with bulk UPDATE command
e7e0c64 Updated Order Entry module and Orders Schema
2cff23e Merge branch 'order_schema'
104b2ce Orders Schema
f7d57cf Order Entry updated to handle and log responses from LC
afa1b7b Merge pull request #18 from project/bugfix/mockvenue
4b2c8d8 Return correct string in mock venue API

现在我想我要压缩上面列出的前5个提交(4363273-f7d57cf).所以我然后运行:

git rebase -i HEAD~5

4363273 Updated Order_Entry with bulk UPDATE command
pick 44768b2 Add script to run simulation on a strategy
pick f82ec8d Implement mock venue
pick f7d57cf Order Entry updated to handle and log responses from LC
pick 4b2c8d8 Return correct string in mock venue API
pick 104b2ce Orders Schema
pick 4363273 Updated Order_Entry with bulk UPDATE command

为什么运行git rebase后显示的提交列表与运行git log时的前5次提交不匹配.特别是,为什么e7e0c64和2cff23e出现在git log中而不是git rebase？

* 4363273 Updated Order_Entry with bulk UPDATE command
*   e7e0c64 Updated Order Entry module and Orders Schema
|\
| *   2cff23e Merge branch 'order_schema'
| |\
| | * 104b2ce Orders Schema
| * |   afa1b7b Merge pull request #18 from project/bugfix/mockvenue
| |\ \
| | |/
| |/|
| | * 4b2c8d8 Return correct string in mock venue API
| |/
* | f7d57cf Order Entry updated to handle and log responses from LC
|/
*   8ed2260 Merge pull request #17 from project/mockvenue

Answer 1

您的图表显示了大量合并.这是问题的根源.值得注意的是,这HEAD~5意味着"后退五步--first-parent".

我们首先介绍一下背景知识.一般来说,你不能改变合并,并且rebase通常不会尝试(它通常只是丢弃它们).使用git rebase -p将尝试保留合并,并且通常会成功,但是交互式使用非常困难(因为编辑脚本没有合并表示).

一旦我们了解了rebase如何工作,我们就能看到更多.假设我们有这样的提交图:

          B - C - D   <-- other-branch
        /
... - A
        \
          E - F - G   <-- your-branch

1. Rebase进行一系列提交,并将其转换为更改集/补丁.也就是说,如果你有承诺E,F以及G随后提交A,混帐必须从产生差异A来E,然后从E以F从,最后F到G.这些代表"如何从基本提交转换"(当前A)"到提示,作为一系列修改."

2. 然后,rebase转向新的基本提交,在本例中为commit D,并按顺序应用这些补丁.从变化A到E,适用于D,使得一个新的提交E'.从变化E到F,应用E',使得新的承诺F'.最后的改变变成了G'.

将提交更改为修补程序(通过将其与其父项进行比较)然后应用修补程序实际上是一个git cherry-pick.换句话说,rebase仅仅是一系列摘樱桃操作,选择提交E,F以及G到一个新的分支从延伸D.新的提交图将如下所示:

          B - C - D   <-- other-branch
        /           \
... - A               E' - F' - G'   <-- your-branch
        \
          E - F - G   [reflog only]

如果我们尝试使用合并提交执行相同的操作,则会遇到问题.合并有两个(或更多)父母,如果没有人工协助,就无法挑选出来:你必须告诉git cherry-pick哪个父母是差异的父母.

什么git rebase -p是重做合并,而不是尝试樱桃挑选.底垫文档有这个例子中,在其中您可以变基A到Q:

                  X
                   \
                A---M---B
               /
       ---o---O---P---Q

它们不显示结果,但它应该看起来像这样(理想情况下,原始A--M--B序列为灰色):

                  X--------
                   \       \
                A---M---B   |
               /            |
       ---o---O---P---Q     |
                       \    |
                        A'--M'--B'

请注意,新提交M'必须是A'和(未更改)提交之间的合并X.如果合并是正常(非"邪恶")合并,这可行,但显然有点棘手,至少.

让我们回到你的特定情况,在git log --graph下面给出了下面的文字(我已经修改了一下).转向侧面有点困难(上面的其他图表左侧有前任提交,右侧有后继提交,而git log --graph输出有下面的前辈和后面的后继者),但是我会快速尝试一下,添加单个每个提交的通信代码:

H   * 4363273 Updated Order_Entry with bulk UPDATE command
G   *   e7e0c64 Updated Order Entry module and Orders Schema
    |\
F   | *   2cff23e Merge branch 'order_schema'
    | |\
E   | | * 104b2ce Orders Schema
D   | * |   afa1b7b Merge pull request #18 from project/bugfix/mockvenue
    | |\ \
    | | |/
    | |/|
C   | | * 4b2c8d8 Return correct string in mock venue API
    | |/
B   * | f7d57cf Order Entry updated to handle and log responses from LC
    |/
A   *   8ed2260 Merge pull request #17 from project/mockvenue

现在A作为最左边的提交和H最右边的提交:

    C---D
   /___/ \
  //__--E-F
 ///       \
A-----B-----G--H

的直接祖先的(第一亲本)线变为从H到G,然后B,再对A.这意味着HEAD~5是一个承诺,我们甚至看不到(二至左A),并git rebase -i HEAD~5应列出所有这些提交除合并的(D,F和G).这将有五个提交:A,B,C,E,和H.但基于其日志消息,A也是一个合并.我们在这里缺少信息,无法绘制完整的图形(由于紧凑形式中有很多行,因此也是如此).

无论如何,这实际上是发生了什么.该rebase命令通过列出从第一个被排除的提交无法访问的提示提交(HEAD即提交H)中可以访问的每个提交来找到提交到提取的提交(提交两个步骤左边的提交,所以我们看不到它).然后抛出合并提交并将挑选每个剩余的提交以构建新的线性分支.HEAD~5A

这是否有意义,以及哪些提交你应该挑选,不是别人可以为你回答的.