出现合并冲突时，如何将多个Git提交压缩为单个提交？

假设你的上游分支为upstream/main，开发分支为my-branch，以下是两种可靠的解决方法：

方法一：交互式变基（推荐） #

1. 拉取上游最新代码：

   git fetch upstream
   

2. 切换到你的开发分支：

   git checkout my-branch
   

3. 基于上游最新主分支执行交互式变基：

   git rebase -i upstream/main
   

4. 编辑器打开后，将第一个提交保留pick，其余所有提交的pick改为s（保留提交信息）或f（丢弃提交信息，合并到前一个提交），保存并退出。
5. 若遇到冲突：
   • 手动修改冲突文件，解决后执行：

     git add <冲突文件名>
     

   • 继续变基流程：

     git rebase --continue
     

   （注意：冲突修复后无需单独提交，--continue会自动完成压缩）
6. 变基完成后，你的分支就只剩一个基于上游最新状态的压缩提交。若之前已推送过该分支到远程，需强制推送：

   git push origin my-branch --force
   

   （团队协作时需确认无其他成员在该分支工作）

方法二：新建分支+合并压缩 #

1. 拉取上游最新代码：

   git fetch upstream
   

2. 基于上游最新主分支创建干净的新分支：

   git checkout -b new-clean-branch upstream/main
   

3. 将原开发分支的所有修改合并到新分支（仅合并修改，不保留提交历史）：

   git merge --squash my-branch
   

4. 手动修复冲突，完成后暂存所有修改：

   git add .
   

5. 提交压缩后的修改：

   git commit -m "你的提交描述"
   

6. 这个新分支即可直接用于向上游提交PR。

为什么之前的方法失效？ #

• git diff/format-patch生成的补丁依赖旧的代码基准，上游更新后补丁与当前代码状态不匹配，导致无法应用。
• 使用git cherry-pick时，你在冲突修复后单独提交，导致多生成一个提交。正确操作是修复冲突后执行git add，再用git cherry-pick --continue，无需单独提交，但该方式本身是逐个处理提交，效率不如前两种方法。

内容的提问来源于stack exchange，提问作者Perdu