我太懂这种需求了——很多开发者都会基于开源项目做定制化改造，同时还得跟上上游的更新节奏，这确实是个非常常见的场景。我来一步步给你拆解最佳实践，顺便解决你遇到的那些具体问题：

首先得把初始的仓库关联逻辑理清楚，避免出现历史不相关的问题：

1. 拉取公共仓库的特定版本到本地
   如果你还没有本地仓库，直接克隆指定版本最省心：

   • 用标签拉取：git clone -b <版本标签> https://github.com/xyz/xyz.git
     比如要拉取v1.2.3版本，就执行 git clone -b v1.2.3 https://github.com/xyz/xyz.git
   • 用提交哈希拉取（如果没有标签的话）：

     git clone https://github.com/xyz/xyz.git
     cd xyz
     git checkout <提交哈希值>
     

2. 关联你的私有仓库作为远程
   把私有仓库添加为本地仓库的远程源（建议用SSH，避免每次输密码）：
   git remote add private git@your-private-repo-url.git

3. 推送到私有仓库
   如果你的私有仓库是空的，直接推送就行：
   git push private main
   如果私有仓库已有内容，且和本地版本无关联，确认要覆盖私有仓库内容的话，可以用强制推送：
   git push -f private main

这个错误的核心原因是：你的本地/私有仓库和公共仓库的提交历史完全没有交集，Git不知道如何合并两者。分两种情况处理：

• 情况1：私有仓库是空的/还没做自定义修改
  直接用上面的强制推送命令覆盖私有仓库，把公共仓库的特定版本作为私有仓库的基础即可，后续的自定义修改都基于这个版本做。

• 情况2：私有仓库已有自定义提交，但和公共仓库无关联
  这种情况不建议强行合并（会导致历史混乱），更稳妥的做法是：

  1. 重新拉取公共仓库的特定版本到新的本地目录
  2. 把私有仓库的自定义提交通过git cherry-pick <提交哈希>一个个迁移到新的本地仓库
  3. 再推送到私有仓库，这样历史就完全关联了

当你已经有了基于公共版本的私有仓库，并且做了自定义修改后，要跟上上游更新的标准流程如下：

1. 拉取公共仓库的最新更新
   先获取公共仓库的最新代码（不会直接合并到本地分支）：
   git fetch github

2. 切换到你的工作分支
   比如你在main分支做自定义修改，就切换过去：
   git checkout main

3. 合并上游更新到本地
   有两种合并方式可选：

   • 普通合并（保留完整历史）：
     git merge github/main
     如果出现冲突，Git会提示你修改冲突文件，解决后执行git add .和git commit完成合并。
   • Rebase变基（让历史更线性）：
     git rebase github/main
     变基会把你的自定义提交“挪”到上游最新提交的后面，历史更干净，但会改写提交历史。如果已经推送过本地分支到私有仓库，需要用git push -f private main强制推送，团队协作时要提前通知其他人。

4. 推送到私有仓库
   合并完成后，把更新后的分支推送到私有仓库：
   git push private main

• 用分支隔离自定义修改：不要直接在主分支做定制化，建议创建专门的自定义分支（比如custom），主分支保持和公共仓库同步。这样更新上游时，先同步主分支，再把主分支合并到custom分支，冲突更容易定位和处理。
• 打标签标记上游版本：每次拉取公共仓库的特定版本后，给私有仓库打个标签（比如upstream-v1.2.3），方便后续追溯是基于哪个上游版本做的修改。
• 优先用SSH认证：不管是公共GitHub还是私有仓库，都配置SSH密钥认证，省去每次拉取推送的密码输入步骤，效率更高。
• 提前查看差异：合并上游更新前，先查看差异：git diff main..github/main，提前了解哪些文件会有冲突，做好准备。

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