Git执行rebase后未同步上游文件删除变更的解决方法

执行rebase后f1.txt没被删掉，基本都是以下三个原因导致的：

• 跑git pull前没刷新远程分支状态，本地存的origin/dev指针还是1个月前切b2时的旧版本，根本没拉到b1合入的删除f1.txt的提交
• rebase过程中触发了f1.txt的冲突（比如你在c2提交里不小心改到过f1.txt、或者本地留着没提交的f1.txt改动），处理冲突的时候误选了保留本地版本，导致上游的删除操作没生效
• 跑pull --rebase的时候git自动把工作区没提交的f1.txt改动暂存了，rebase完自动把暂存内容恢复回来，相当于把上游已经删掉的文件又拷回了本地

按照以下流程操作可以100%同步上游的文件删除变更，不会出现文件残留：

• 先清理本地工作区，避免未提交内容干扰rebase逻辑
  执行git status查看工作区状态，如果有未提交的改动，要么先commit到本地分支，要么执行git stash临时暂存，等同步完成后再恢复。
• 拉取最新的远程分支状态，刷新本地的远程分支指针缓存
  执行git fetch origin dev，这一步不会改动你当前分支的代码，只会把远程最新的dev提交信息同步到本地。
  可以执行git ls-tree origin/dev f1.txt验证上游状态，如果命令返回空，说明远程dev确实已经删除了f1.txt。
• 执行rebase将本地提交重放到最新的上游dev上
  执行git rebase origin/dev

  如果过程中弹出f1.txt相关的冲突，提示「上游删除了文件，本地存在修改」，确认不需要保留f1.txt的本地改动时，直接执行git rm f1.txt标记冲突解决，再执行git rebase --continue走完流程即可。

• 校验同步结果
  rebase完成后执行ls f1.txt，如果提示文件不存在就说明同步成功。
  如果这时候文件仍然存在，说明你本地b2的提交历史里存在显式新增f1.txt的记录，直接执行git rm f1.txt && git commit -m "sync: remove f1.txt deleted from upstream"提交删除记录即可，后续合入dev不会产生冲突。

绝对不要在工作区留着目标文件的未提交改动时直接跑git pull --rebase，git自带的自动暂存+恢复逻辑会把被上游删掉的文件重新放回本地，看起来就像rebase根本没同步到删除操作一样。

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