从一个 Git 仓库迁移到另一个 GitHub 仓库：完整实战指南（含 non-fast-forward 解决方案）

适用场景：

• fork / clone 开源项目后，迁移到自己的 GitHub
• 把本地项目“改投”到新的远程仓库
• 从使用者升级为维护者
• 彻底理解 Git 的 non-fast-forward 错误

---

一、问题背景：为什么我 push 会被拒绝？

在实际开发中，一个非常常见的场景是：

• 本地已经 clone 了一个 Git 项目（例如开源项目）
• 后来在 GitHub 上新建了一个自己的仓库
• 希望把当前整个项目推送到这个新仓库中

于是我们自然会做这件事：

git remote remove origin
git remote add origin https://github.com/yourname/your-repo.git
git push -u origin main

结果却得到一个非常经典、但初看很懵的错误：

! [rejected] main -> main (fetch first)
error: failed to push some refs
hint: Updates were rejected because the remote contains work that you do not have locally.

这不是你操作错了，而是 Git 在保护历史一致性。

---

二、核心原理：Git 为什么拒绝你？

一句话解释：

远程仓库已经有提交了，而你的本地分支历史并不包含它

最常见的触发原因：

• GitHub 在你建仓库时自动创建了：

  • README.md
  • LICENSE
  • .gitignore
• 这些文件形成了 一个新的 commit
• 而你的本地仓库历史，来自另一个项目

此时 Git 发现：

远程 main:   A ── B
本地 main:        C ── D ── E

历史出现分叉，Git 不允许你直接覆盖，于是拒绝 push。

这就是所谓的 non-fast-forward。

---

三、推荐解法（工程师级，安全且标准）

✅ 使用 rebase，把远程历史“接进来”

这是最推荐、最干净、可长期复用的做法。

1️⃣ 拉取远程提交（使用 rebase）

git pull origin main --rebase

这一步做了三件事：

1. 拉取远程仓库已有的提交
2. 暂存你本地的所有提交
3. 把你的提交重新接在远程提交之后

结果是：一条直线历史，没有 merge 噪音。

---

2️⃣ 推送到新仓库

git push -u origin main

至此：

• 所有历史完整保留
• GitHub 上的仓库变成你的主线
• 后续 push 不再有任何问题

---

四、如果出现冲突，如何处理？

如果 Git 提示冲突（常见于 README.md）：

处理流程固定三步：

1. 打开冲突文件，保留你想要的内容
2. 标记冲突已解决

git add .

3. 继续 rebase

git rebase --continue

直到 rebase 完成即可。

---

五、不推荐但你必须知道的方案：强制覆盖

如果你 100% 确定：

• 远程仓库只是空壳
• 那些初始提交完全不需要

可以使用：

git push -u origin main --force

⚠️ 注意事项：

• 会直接抹掉远程已有提交
• 团队项目中是事故级操作
• 个人仓库、实验项目可以接受

知道它存在即可，不要养成习惯。

---

六、进阶实践：把原仓库保留为 upstream（强烈推荐）

如果你是从一个开源项目迁移而来，最佳实践是：

• origin → 你自己的仓库（主线）
• upstream → 原项目（同步源）

添加 upstream

git remote add upstream https://github.com/original-org/project.git

查看：

git remote -v

以后同步原项目更新

git fetch upstream
git rebase upstream/main
git push

这一步，意味着你从“使用者”升级为：

有能力长期维护自己分支的工程师

---

七、完整操作流程速查（可直接复制）

# 进入项目目录
cd Open-AutoGLM

# 修改远程仓库
git remote remove origin
git remote add origin https://github.com/yourname/Open-AutoGLM.git

# 拉取并重排历史
git pull origin main --rebase

# 推送
git push -u origin main

#（可选）添加 upstream
git remote add upstream https://github.com/original-org/Open-AutoGLM.git

---

八、总结：这不是 Git 技巧，而是工程意识

这次问题本质不是“命令记不住”，而是：

• 是否理解 Git 在保护什么
• 是否尊重 历史一致性
• 是否知道 什么时候该 rebase，什么时候该 force

一旦理解这些，Git 会从“麻烦制造机”
变成一个极其可靠的工程时间机器。

这类问题你以后一定还会再遇到，
而这篇文章，就是你未来的“自己给自己的答案”。