Git分支经rebase改写历史并force push后，另一台机器如何拉取更新？

报错的核心原因 #

你在第二台机器上留存的Branch1分支，还存着force push之前的3个零散提交；而远端的Branch1已经被第一台机器的rebase squash改写成了全新的提交，两条提交链根本没有可以直接快进（fast-forward）的衔接关系。默认的git pull会触发合并逻辑，硬要把两条不兼容的提交链拼到一起，自然会报错，甚至生成毫无意义的合并提交。

具体操作步骤 #

全程不需要重新抓取全仓库数据、也不需要在第二台机器上重复执行squash合并操作，按顺序执行即可：

• 第一步，确认本地改动安全：运行git status检查工作区状态，如果有未提交的零散改动，先执行git stash暂存，避免后续操作丢失内容。
• 第二步，同步远端最新的提交元数据和内容对象：运行git fetch origin，这一步只会把远端分支的最新状态同步到本地的远端跟踪分支，不会改动你本地的分支指针。
• 第三步，对齐本地分支和远端的状态：
  • 如果当前不在Branch1分支上：直接执行git branch -f Branch1 origin/Branch1，把本地的Branch1分支指针强制指向远端最新的位置即可。
  • 如果当前正处在Branch1分支上：执行git reset --hard origin/Branch1，直接把本地分支的工作区、暂存区、分支指针全部对齐到远端最新的Branch1状态。

注意事项 #

• 整个操作会丢弃本地Branch1上留存的旧零散提交（也就是之前的Commit1/2/3），这部分改动在第一台机器生成的squash提交里已经完整包含，不会产生内容损失——只要你本地没有藏着未推送到远端的新增改动，就完全不用担心内容丢失。
• 不要尝试用默认参数的git pull、或是在第二台机器上手动跑rebase去对齐历史，这种操作会把本地留存的3个旧零散提交重新叠到远端的squash提交之上，生成重复的内容提交，把分支历史搞的更乱。

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