已推送分支的提交历史压缩操作疑问及分支适配咨询

先给你吃个定心丸：你的操作方向是对的，但需要调整几个细节步骤，就能解决遇到的问题，同时达到你期望的提交历史效果。

一、为什么日志还显示原两个提交？ #

你在exp-squash分支上完成了提交压缩，但原master分支的历史并没有被修改——你只是在实验分支上创建了一套新的提交历史，而master仍然指向包含合并提交d68bebe和那两个未压缩提交的旧版本。只有当你把master分支更新到exp-squash的状态后，原提交才会从master的日志中消失（Git不会立刻删除这些旧提交对象，只是不再被分支引用，后续会自动垃圾回收）。另外，远程仓库的origin/master也不会自动同步，必须通过强制推送才能更新远程历史。

二、如何让enh/12-durability适配新的提交历史？ #

enh/12-durability是基于旧的master创建的，当master的历史被改写后，你需要把这个特性分支的提交重新应用到新的master上，具体步骤如下：

步骤1：确认实验分支结果并更新master #

1. 切换回master分支：

   git checkout master
   

2. 将master强制指向exp-squash的最新提交（注意：如果团队里有其他人基于当前master工作，一定要先沟通确认，避免影响他人工作）：

   git reset --hard exp-squash
   

3. 强制推送到远程仓库：

   git push --force origin master
   

步骤2：同步enh/12-durability分支 #

1. 切换到特性分支：

   git checkout enh/12-durability
   

2. 执行变基操作，把分支上的提交重新应用到新的master上：

   git rebase master
   

3. 如果遇到冲突，解决冲突后执行git rebase --continue完成变基；实验分支没用的话可以删除：

   git branch -D exp-squash
   

4. 最后强制推送更新后的特性分支到远程：

   git push --force origin enh/12-durability
   

三、优化到你期望的提交历史结构 #

看你期望的日志，你希望保留master中的合并提交d68bebe，同时把enh/7-introducing-clock-ticks分支的两个提交压缩成一个。其实更稳妥的操作是先压缩特性分支的提交，再重新合并到master，这样能避免直接改写master的历史（风险更低）：

1. 切换到enh/7-introducing-clock-ticks分支：

   git checkout enh/7-introducing-clock-ticks
   

2. 压缩该分支的两个提交：

   git rebase -i f699930
   

   在弹出的编辑器中，把2b16710的指令改成fixup（或缩写f），保存退出后会生成合并后的新提交。
3. 强制推送更新后的特性分支：

   git push --force origin enh/7-introducing-clock-ticks
   

4. 回到master分支，先回退到合并前的状态：

   git reset --hard f699930
   

5. 重新合并压缩后的特性分支：

   git merge enh/7-introducing-clock-ticks
   

   这样master会生成一个新的合并提交，完全匹配你期望的日志结构。

四、是否需要cherry-pick？ #

不需要。cherry-pick适合单独挑选某几个提交迁移到其他分支，而你的enh/12-durability分支包含连续的两个提交，用git rebase更合适——它能完整保留分支的提交顺序和关联，同时自动处理与新历史的冲突。

内容的提问来源于stack exchange，提问作者Kamil Gierach-Pacanek