您可以进行交互式变基并手动选择要压缩的提交。这将重写您的dev
分支的历史记录,但由于您没有推送这些提交,因此除了您自己的计算机上可能发生的事情之外,不应该有任何负面后果。
从以下内容开始:
git checkout dev
git rebase -i HEAD~6
这应该会打开一个窗口,显示以下 7 个提交的列表,从dev
分支的 HEAD 返回 6 个步骤:
pick 07c5abd message for commit A
pick dl398cn message for commit B
pick 93nmcdu message for commit C
pick lst28e4 message for commit D
pick 398nmol message for commit E
pick 9kml38d message for commit F
pick 02jmdmp message for commit G
显示的第一个提交(A
上面)是最旧的,最后一个是最近的。您可以看到默认情况下,每个提交的选项是pick
. 如果您现在完成了 rebase,您将只保留每个提交,这实际上是一个无操作。但是由于您想压缩某些中间提交,请编辑并将列表更改为:
pick 07c5abd message for commit A
pick dl398cn new commit message for "H" goes here
squash 93nmcdu message for commit C
squash lst28e4 message for commit D
pick 398nmol message for commit E
pick 9kml38d message for commit F
pick 02jmdmp message for commit G
仔细注意上面发生的事情。通过键入squash
,您是在告诉 Git 将该提交合并到它上面的提交中,这是紧接在它之前的提交。所以这表示将提交D
向后压缩到提交C
,然后压缩C
到B
,只留下一个提交用于提交B
,C
和D
。其他提交保持原样。
保存文件(: wq在 Windows 中的 Git Bash 上),rebase 完成。请记住,您可能会像预期的那样从中获得合并冲突,但是解决它们并没有什么特别之处,您可以像使用任何常规变基或合并一样继续。
如果您在变基后检查分支,您会注意到E
、F
和G
提交现在具有新的哈希、日期等。这是因为这些提交实际上已被新提交替换。这样做的原因是您重写了历史记录,因此一般的提交不能再与以前相同。