你遇到的问题其实很常见——哪怕你自己没在master分支做过任何提交，上游仓库如果用了 squash 或者 rebase 方式合并PR，就会导致你的fork仓库master分支的提交历史和上游不一致，直接rebase就会触发大量无意义的冲突。

不用手动处理几百个冲突，直接用强制重置的方式就能一键让你的fork和上游完全同步，步骤如下：

1. 确认上游远程仓库已配置 #

如果你还没添加上游仓库（或者不确定配置是否正确），先执行：

git remote add upstream https://github.com/Microsoft/perfview.git

可以用git remote -v检查输出，确保upstream指向正确的上游仓库地址。

2. 拉取上游最新代码 #

先获取上游仓库的所有最新提交：

git fetch upstream

3. 切换到本地master分支 #

确保你在要同步的目标分支上（这里是master）：

git checkout master

4. 强制重置本地master到上游最新状态 #

这个命令会直接把本地master分支的状态完全替换成上游master的最新状态，所有本地差异都会被丢弃（因为你确认自己没在master提交过，所以完全安全）：

git reset --hard upstream/master

5. 强制推送到你的Fork仓库 #

因为本地分支的历史已经被改写，需要用强制推送覆盖远程fork的master分支：

git push origin master --force

完成这几步后，你的fork仓库master分支就和上游完全一致了，没有任何冲突。之后你直接基于这个同步后的master创建新特性分支即可：

git checkout -b your-new-feature-branch

为什么之前的rebase会出问题？ #

当上游仓库用squash merge或者rebase merge处理PR时，你的fork仓库里的PR提交记录会和上游的提交历史不一致——上游是一个新的squashed提交，而你的fork里保留了原来的多个提交。这时候用rebase，Git会试图把这些“旧”提交重新应用到上游最新代码上，自然会触发大量冲突。而reset --hard则是直接跳过历史对比，让本地分支完全对齐上游，从根源上避免了冲突。

⚠️ 注意：git reset --hard是不可逆操作，一定要确保本地master分支没有你自己的未提交/未推送修改。你已经确认没在master做过提交，所以可以放心执行。

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