第一次把项目并入别人的 GitHub 仓库：从 README 到 Pull Request

2026-09-29 更新于 2026-09-29

今天想把自己写的项目放进别人创建的 GitHub 仓库。起初我以为“推送到 main”就是把当前文件夹直接传上去，后来才弄明白：我的项目文件夹当时甚至不是 Git 仓库，而目标仓库已经有自己的内容。直接覆盖或强推都可能伤到别人的文件。

这篇是我按当时的操作讨论整理的备忘。文中的仓库名、路径和分支名都是示例。那次只整理了本地 README 和一份技术记录，没有完成 Git 提交、推送或合并。下面的命令是后续准备采用的步骤，不能当作已经执行的记录。

先弄清几个位置

名称	在这次操作中是什么
`D:\my-project`	我现有的项目文件夹，当时没有 `.git`，所以不能在这里直接 `git push`。
`example-owner/team-repo`	对方创建并邀请我协作的目标仓库，里面原本就有内容。
`main`	目标仓库的主分支，最终希望把项目并进去。
`add-my-project`	我准备创建的工作分支，先在这里提交，再发起 Pull Request。
博客目录	我写这篇文章的地方，和目标仓库是两回事。

Git 里的“提交”是把改动记录在本地仓库；“推送”才是把本地分支送到远端仓库；Pull Request（简称 PR）是请求把工作分支合并到主分支。这三件事不是同一步。

先接受 GitHub 协作邀请。在一个空目录的上级目录打开 PowerShell，克隆目标仓库，再从它当前的 main 建一个工作分支：

1
2
3

git clone git@github.com:example-owner/team-repo.git
cd team-repo
git switch -c add-my-project

git clone 会下载仓库内容和 Git 历史；cd 进入克隆出来的目录；git switch -c 新建并切换到分支。这里的 SSH 地址要求电脑已配置 GitHub SSH 认证；如果没有，可以使用该仓库页面给出的 HTTPS 克隆地址。

为什么从对方仓库克隆？ 这样本地一开始就有对方现有的文件和提交历史，可以看清自己会改动什么。原来的 D:\my-project 只是待复制的项目文件，不要把它当作目标仓库的替身。

原计划是把项目放进 my-project 子目录，避免和对方仓库根目录的文件重名。但我后来已经把项目文件直接放在克隆仓库的根目录。这时最该检查的是原有 README.md 是否被自己的版本覆盖，以及有没有意外改动或删除对方的文件。发现冲突就先和仓库所有者确认放置方式，再继续。

依赖目录 node_modules 不需要复制。项目里的测试样本是否适合公开尚未决定，也先不要暂存。若最终不提交样本，README 中依赖样本的测试说明也要对应修改。

因为文件放在根目录，原计划的 git add my-project 已经不适用。我需要在克隆出的 team-repo 目录里执行（文件名按实际情况替换）：

git status --short
git add -- README.md docs src package.json package-lock.json
git diff --cached --name-status
git diff --cached --check

这些命令分别在做什么：

git status --short：列出新增、修改、删除的文件。先确认自己究竟复制了哪些东西。
git add -- ...：只把列出的路径放进“暂存区”，准备纳入下一次提交。-- 后面是文件名或目录名；实际文件清单变了，就按实际情况调整。这里不要图省事直接 git add -A，以免把 node_modules 或尚未决定公开的样本一起带上。
git diff --cached --name-status：看已暂存文件的状态。A 是新增，M 是修改，D 是删除。若出现意外的 M 或 D，尤其是原仓库的 README，先停下来核对具体差异：git diff --cached -- README.md。
git diff --cached --check：检查暂存内容中的空白字符等格式问题。它通过也不代表内容安全，仍要看文件清单和实际差异。