当我运行类似 git rebase -i --rebase-merges eeb1425e0
我的提交列表是颠倒的,即第一个提交是最后一个,最后一个提交是第一个。
pick A Penultimate commit
pick B Penult commmit
pick C Latest commit
# Rebase eeb1425e..5a3f045b onto eeb1425e (288 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
然后,当 "压扁 "选项显示 squash = use commit, but meld into previous commit
,我推 squash
如下。
pick A Penultimate commit
squash B Penult commmit
pick C Latest commit
上次提交的 B
是 A
或 C
? 是 B
将会被合并到一起 A
或 C
?
相关内容。
提交的顺序确实和你平时看到的倒过来了 git log
,所以对于。
pick A Penultimate commit pick B Penult commmit pick C Latest commit
如果你把第二行改为 squash
,Git会。
A
到 开始 做出新的提交,但还没有做出。B
在实际进行新的提交之前,将其纳入其中;以及C
来做第二次新的承诺。给你我喜欢画的东西,图文并茂,如:
A--B--C [abandoned]
/
...--o--o--AB--C' <-- branch-name
在这里... A-B-C
链是原来的三个承诺,最后一个承诺画在右边(而不是顶部或底部),而新的 AB-C'
链上的两个新提交,同样是最后一个在右边。 您的分支名称用于标识提交 C
,现在可以识别新的副本 C'
.
附注:第三名倒数第二名的词是......。倒数第二. "倒数第二 "的字面意思是 "倒数第二". 如果你需要识别最后一个的第四个,这就是... 前期和后期. 似乎没有 "倒数第五 "的英文单词。 按照这里的链接,可以看到 前期但见 状况 比如说。
另一个附带说明:交互式rebase愿意先做提交,然后再取消提交,所以上面的描述("在实际做提交之前先压扁")只是你要做的事情的简写。看到 当你看结果时,而不是底层机制的完整描述。 实际的提交集可能包括额外的放弃的临时提交。 Git最终会自行清理这些。