Git交互式变基时遭遇foo.txt二进制文件无法合并警告

嘿，我来帮你搞定这个Git的问题！

首先得弄明白为什么会出现这个警告：你先是多次修改foo.txt，然后删除再重建它并写入ver11提交。当你用git rebase -i调整最后那次删除重建的提交位置时，Git需要把这些提交的变更按新的顺序重新应用到分支上。但删除重建文件的操作和之前的多次修改操作凑在一起，Git没法自动判断怎么合并这些变更——毕竟你相当于先改了11次文件，然后又把它删了重写，调整顺序后Git就懵了，所以抛出了“无法合并二进制文件”的警告（哪怕foo.txt是文本，这种极端的变更也会让Git这么提示）。

接下来给你几个解决方案，看哪种符合你的需求：

方案一：直接把所有提交整合成一个（最省心） #

如果你的目标是让提交历史里只有一个提交，最终foo.txt就是ver11，那不用折腾调整顺序，直接把所有提交 squash 到一起就行：

1. 找到你第一次创建foo.txt的那个提交的SHA1（用git log --oneline就能看到，最上面的那行是最新提交，往下翻第一个创建文件的提交就是）。
2. 执行命令：

   git rebase -i <第一次提交SHA1>~1
   

   这里的~1是让Git把第一次提交也包含到变基列表里。
3. 弹出编辑器后，把除了你想保留的那个提交（比如最后那次ver11的提交）之外的所有行的pick改成squash（或者简写s）。比如你想保留最后一次提交作为最终版本，就把前面11次提交的pick都改成s，最后一次留pick。
4. 保存退出后，Git会让你编辑合并后的提交信息，写完保存就搞定了。

方案二：手动解决变基冲突（如果你一定要调整提交顺序） #

如果坚持要调整提交顺序并合并，那就得手动处理冲突：

1. 变基暂停后，先看一下当前状态：

   git status
   

   你会看到foo.txt处于冲突状态。
2. 直接用你想要的最终内容覆盖foo.txt就行：

   echo "ver11" > foo.txt
   

3. 标记冲突已解决：

   git add foo.txt
   

4. 继续变基：

   git rebase --continue
   

5. 如果还有其他冲突，重复上面的步骤，直到变基完成。

方案三：用reset+amend快速合并到目标提交 #

如果你只是想把最后那次删除重建的内容合并到第11次提交里，让第11次提交直接变成最终的ver11状态，这个方法更简单：

1. 找到第11次提交（也就是你删除foo.txt之前的那次提交）的SHA1，执行：

   git reset --soft <第11次提交SHA1>
   

   --soft会保留当前工作区的内容，只是把HEAD移到第11次提交的位置。
2. 把当前的foo.txt添加到暂存区：

   git add foo.txt
   

3. 把当前的变更合并到第11次提交里：

   git commit --amend
   

4. 编辑提交信息后保存，就完成了——现在第11次提交就是最终的ver11状态，之前的删除重建提交也被整合进去了。

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