您可以执行交互式 rebase 并手动选择要压缩的提交记录。 这将重写您的 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,那么您只会保留每个提交,这实际上就是一个no-op操作。但是,由于您想压缩某些中间提交,因此请编辑并将列表更改为如下内容:
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
。其他提交保持不变。
保存文件(在Windows上使用Git Bash键入: wq ),重定基完成。请注意,可能会像预期的那样遇到合并冲突,但解决它们没有什么特别之处,您可以像进行常规重定基或合并一样继续。
如果在重定基后检查分支,您会注意到E
、F
和G
提交现在具有新的哈希、日期等信息。这是因为这些提交已被新提交所取代。原因是您重写了历史记录,因此提交记录通常不能与以前完全相同。