如何将克隆的开源项目发布到自己的GitHub，并优雅地合并上游更新#
我的项目CalicoHaro基于一个非常棒的开源项目YANG-Haruka/LinguaHaru，我按照自己的想法修改了一些代码，加入了一些个性化的内容。现在，我需要将这些改动发布到我自己的GitHub仓库，并且希望未来能方便地从原作者的仓库获取更新。
当前状态确认：
运行 git remote -v ，输出如下：
PS D:\_Files\Project\github\LinguaHaru> git remote -v
origin https://github.com/YANG-Haruka/LinguaHaru.git (fetch)
origin https://github.com/YANG-Haruka/LinguaHaru.git (push)这表明你的本地仓库的 origin 远程地址指向了原始项目，而不是你自己的GitHub仓库。这是我们首先需要解决的问题。
我的情况：#
我的项目位于 D:\_Files\Project\github\LinguaHaru，其中包含了从 YANG-Haruka/LinguaHaru 复制（或克隆）过来的基础代码，并且我已经对其进行了修改。现在，我需要将这些改动发布到我自己的GitHub仓库（例如：https://github.com/你的用户名/LinguaHaru.git），同时保留与 YANG-Haruka/LinguaHaru 原始仓库的连接，以便将来获取更新。
操作步骤：#
整个过程的核心思想是：首先将原始仓库重命名为 upstream，然后将你自己的GitHub仓库设置为新的 origin，完成首次推送。之后，再通过 upstream 拉取原始项目的更新并合并。
零、在GitHub上创建你自己的新仓库 (如果尚未创建)#
在开始之前，请确保你已经在GitHub上创建了一个新的空的仓库，用于存放你的 LinguaHaru 项目。例如，你可以创建一个名为 LinguaHaru 的仓库。记下它的HTTPS地址，例如 https://github.com/你的用户名/LinguaHaru.git。
第一步：进入项目目录#
首先，在你的命令行工具（比如 Git Bash）中进入到你的项目根目录：
cd D:\_Files\Project\github\LinguaHaru第二步：重新配置远程仓库地址#
这是最关键的一步。由于你当前的 origin 指向了原始项目，我们需要对其进行调整。
检查当前远程仓库：
git remote -v你会看到类似以下内容：
origin https://github.com/YANG-Haruka/LinguaHaru.git (fetch) origin https://github.com/YANG-Haruka/LinguaHaru.git (push)将原始项目的
origin重命名为upstream： 这将把https://github.com/YANG-Haruka/LinguaHaru.git这个地址关联到upstream这个别名，以便将来获取它的更新。git remote rename origin upstream添加你自己的GitHub仓库作为新的
origin： 现在，你需要把你自己的GitHub仓库地址添加为origin。请将https://github.com/你的用户名/LinguaHaru.git替换为你实际的仓库地址。git remote add origin https://github.com/你的用户名/LinguaHaru.git再次检查远程仓库，确认配置：
git remote -v现在你应该能看到类似以下内容：
origin https://github.com/你的用户名/LinguaHaru.git (fetch) origin https://github.com/你的用户名/LinguaHaru.git (push) upstream https://github.com/YANG-Haruka/LinguaHaru.git (fetch) upstream https://github.com/YANG-Haruka/LinguaHaru.git (push)这表明你已经成功设置了
origin指向你自己的仓库，upstream指向原始仓库。
第三步：首次推送你的魔改版本到自己的仓库#
现在，你的本地仓库已经准备就绪，可以推送到你自己的GitHub仓库了。
git push -u origin maingit push: 将本地更改推送到远程仓库。-u(或--set-upstream): 设置origin/main作为当前本地分支main的上游（跟踪）分支。这样，以后你只需要运行git push或git pull，Git 就会知道推送到哪个远程分支。origin: 推送的目标远程仓库别名。main: 推送的本地分支名称（如果你的主分支是master，请相应替换）。
至此，你的“魔改”版本已经成功发布到了你自己的GitHub仓库！
第四步：获取上游（原始）仓库的更新#
将来，当原始项目 YANG-Haruka/LinguaHaru 有了新的更新时，你可以从 upstream 远程仓库拉取最新的代码和分支信息：
git fetch upstream这个命令只会下载更新到你的本地，不会自动合并到你当前工作的分支。它会把 upstream 仓库的所有分支更新下载到本地，并存储为 upstream/main、upstream/dev 等形式。
第五步：合并上游更新#
现在到了关键一步，将从 upstream 拉取到的更新合并到你自己的分支上。我当前在 main 分支工作：
git merge upstream/main请根据实际情况将 main 替换为你自己和原始仓库的主分支名称。
Git 会尝试将 upstream/main 分支的更改合并到你当前所在的 main 分支。
可能出现的错误及解决方案： fatal: refusing to merge unrelated histories
这个错误表明 Git 认为你的本地仓库（你目前的 main 分支）和 upstream/main 分支的历史是完全独立的，它们没有任何共享的提交。这通常发生在你不是通过 git clone 而是直接下载代码后 git init，或者你在本地仓库创建历史后，才试图合并一个没有共同祖先的远程历史。
Git 默认阻止合并不相关的历史，是为了防止你意外地合并两个完全不同的项目，导致混乱的提交历史。但是，在你知道这两个项目实际上是相关的（你的项目基于原始项目）并且你确实想合并它们的情况下，你需要显式地告诉 Git 允许合并不相关的历史。
解决方法是在 git merge 命令后面加上 --allow-unrelated-histories 选项：
git merge upstream/main --allow-unrelated-histories注意： 通常这个选项只在首次合并两个不相关的历史时需要。一旦你成功合并了一次，它们就有了共同的提交历史，后续的合并就不再需要这个选项了。
第六步：解决冲突 (如果出现)#
合并操作后，如果你的修改和原始项目的更新在同一个地方发生了重叠，Git 就无法自动决定保留哪个版本，从而产生冲突。
查看冲突文件： Git 已经标记了所有冲突的文件。你可以通过运行
git status来再次查看冲突文件的列表。冲突文件会显示在 “Unmerged paths” 部分。git status输出的一部分，
Unmerged paths表示冲突文件，这部分是需要手动解决冲突的：Unmerged paths: (use "git add <file>..." to mark resolution) both added: .github/workflows/deploy.yml both added: .gitignore both added: .vitepress/config.ts # ... 其他冲突文件 ...手动解决冲突： 对于每个冲突文件，你需要手动编辑它们，并处理 Git 添加的冲突标记 (
<<<<<<< HEAD,=======,>>>>>>> upstream/main)。 打开每个冲突文件，你会看到类似以下的结构：<<<<<<< HEAD // 这是你在本地 main 分支的修改 console.log("My custom feature"); ======= // 这是从 upstream/main 分支拉取到的原始仓库的修改 console.log("New feature from upstream"); >>>>>>> upstream/main你需要手动编辑这些文件：
- 找到冲突标记 (
<<<<<<< HEAD,=======,>>>>>>> upstream/main)。 - 仔细阅读
<<<<<<< HEAD到=======之间（你本地的修改）和=======到>>>>>>> upstream/main之间（原始仓库的修改）的代码。 - 手动修改这部分代码，保留你想要的部分，并删除所有的冲突标记。
- 找到冲突标记 (
标记冲突已解决然后推送：
git add <解决冲突的文件名>
git commit -m "Merge updates from upstream YANG-Haruka/LinguaHaru"
git push origin main