Skip to content
远程仓库与协同工作
Git 的记录存储是自包含的：只要 .git 目录完好，就能查看完整历史、创建分支、合并提交，无需任何外部依赖。这种独立性保证了本地操作始终高效，但多人协作需要一个交换提交的中转站，否则各人的仓库会变成相互隔绝的孤岛。
远程仓库就是这样的中转站。它通常托管在独立的服务器上（GitHub、GitLab、公司内部的 Git 服务），存放着与本地相同结构的仓库副本。远程仓库不直接执行工作目录下的修改操作，只负责收发对象数据。
在实际流程中，远程仓库承担两个角色：
- 读取（fetch/pull）：把其他人的提交同步到本地
- 写入（push）：把本地提交发布到共享仓库，供其他人拉取
远程与本地之间的交互通过远程引用管理。远程引用是配置里记录的一个别名，指向远端 URL，同时会在本地维护对应的远程跟踪分支（refs/remotes/<远程名>/<分支>）。
添加与查看远程仓库
通过 git remote add 添加一个远程仓库：
bash
git remote add origin https://github.com/user/repo.git这条命令只做两件事：在 .git/config 中追加 [remote "origin"] 段，记录 URL 和 fetch 规格；不会立即抓取数据，也不会创建远程跟踪分支。
可以配置多个远程仓库，分别指向不同地址。例如，origin 常指向你 fork 后的个人仓库，upstream 指向原始仓库。名称只是本地别名，可以自由定义。
查看已配置的远程列表：
bash
git remote -v输出会列出每个别名的 fetch 和 push URL，例如：
origin https://github.com/user/node-fork.git (fetch)
origin https://github.com/user/node-fork.git (push)
upstream https://github.com/nodejs/node.git (fetch)
upstream https://github.com/nodejs/node.git (push)要查看某个远程的更详细信息，使用 git remote show <remote>，它会列出该远程的所有跟踪分支、本地分支与远端分支的映射，以及 git push 的默认行为。
另一种常见的远程添加方式是克隆：在创建本地仓库的同时，自动配置远程引用。
克隆远程仓库
git clone 是一组自动化操作：创建新目录、初始化 Git 仓库、在配置中写入名为 origin 的远程引用，然后抓取该远程的所有对象和引用。
bash
git clone https://github.com/nodejs/node.git执行后会生成 node 目录，其中已经包含完整的仓库历史。内部的连接关系也自动接好：
- 远程引用
origin指向克隆时使用的 URL； - 远端仓库的每一个分支都会在本地建立远程跟踪分支，例如
origin/main、origin/v16.x-staging； - 基于远端默认分支（一般是
main）检出一个同名本地分支，并设定该本地分支跟踪origin/main。
因此，克隆结束后，本地的 main 已经与远端的 main 建立了隐式的跟踪连线，这直接影响后续 push 和 pull 的默认行为。
如果希望克隆到指定目录，可以加上目录参数：
bash
git clone https://github.com/nodejs/node.git my-node不管哪种写法，克隆所得的远程跟踪分支都是只读的“远端状态镜像”，用于对照本地与远端之间的差异。
远程跟踪分支
远程跟踪分支是 git clone 或 git fetch 后在本地自动生成的只读引用，路径为 refs/remotes/<远程名>/<分支>，例如 refs/remotes/origin/main。这些分支不能被直接检出修改，只记录上一次与远端通信时对方仓库对应分支的顶端提交。
列出所有远程跟踪分支：
bash
git branch -r
origin/HEAD -> origin/main
origin/main
origin/v16.x-staging其中 origin/HEAD 是一个符号引用，表示远端仓库的默认分支，git clone 就是据此决定要检出哪个分支。
远程跟踪分支与本地分支的关系通过上游分支设定。执行 git branch -vv 可以查看每个本地分支跟踪的是哪个远程跟踪分支：
$ git branch -vv
* main 8a3f2c1 [origin/main] Update README
feature 91db7e2 [origin/feature] Add login当上游分支设置好之后，git push、git pull 在不指定参数时默认作用于这个关联的远端分支。
新创建的本地分支不会自动跟踪任何远程跟踪分支，除非使用 --track 选项，或在第一次推送时带上 -u 参数（如 git push -u origin feature/login）。
获取更新：fetch 与 pull
从远程获取更新有两种命令：git fetch 和 git pull，它们的行为有本质区别。
fetch：只下载，不合入
git fetch <remote> 联系指定的远端，把本地不存在的对象（提交、文件、树）下载到 .git/objects，同时更新本地的远程跟踪分支指针。
bash
git fetch origin执行后：
- 本地工作目录和暂存区的内容完全不变；
- 当前所在分支的 HEAD 不会被移动；
- 只有
origin/main、origin/feature这类远程跟踪分支被更新到远端最新位置。
这相当于从服务器取得一份最新的状态快照，但并不将其合并到本地分支。之后可以自行选择时机进行 git merge 或 git rebase，把那些提交整合进来。
pull：下载并合入当前分支
git pull <remote> <branch> 等价于先 git fetch，然后紧接着一个合并操作。默认行为是 fetch + merge；如果配置了 pull.rebase true，则会变为 fetch + rebase。
bash
git pull origin mainpull 在执行的同时会改变当前分支的内容，合并或变基的过程中可能产生冲突。如果本地有未提交的变更或者状态混乱，pull 可能直接报错，甚至留下难以清理的局面。因此，如果只是想检查远端有没有新提交，而不打算立即合并，应该使用 fetch 而不是 pull。
区分与适用场景
| 操作 | 是否修改工作区 | 是否移动当前分支 | 冲突风险 |
|---|---|---|---|
fetch | 否 | 否 | 无 |
pull | 是 | 是 | 可能在合并阶段产生 |
一个推荐的做法是：
git fetch origin下载远端更新；git log HEAD..origin/main或git diff main origin/main检查对方做了什么；- 确认后再决定是
git merge origin/main或git rebase origin/main，或者暂时不整合。
相比直接 git pull，这一流程更加可控。尤其当本地已有未推送的提交时，直接拉取很容易制造无谓的合并提交。
推送修改：push
git push 把本地提交传输到远程仓库，并更新远程分支指针。默认情况下，git push 会推送当前分支到其上游分支（如果有设置）。也可以显式指定远程和分支：
bash
git push origin main推送成功的条件是快进式推送：远程分支的当前历史必须是本地分支历史的子集，即你的提交建立在远端已有提交的基础上。如果远端已经包含本地没有的新提交，推送会被拒绝：
$ git push origin main
To https://github.com/user/repo.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/user/repo.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. ...这个机制是为了防止覆盖他人的提交。
第一次推送一个新分支时，若该分支没有上游设置，需要使用 -u 参数同时建立跟踪关系：
bash
git push -u origin feature/login这条命令会将本地 feature/login 推送到远端的同名分支，并设置 origin/feature/login 为上游。之后在此分支上直接执行 git push、git pull 就无须再指定远端和分支名。
处理推送冲突
当推送被拒绝，意味着远端已经存在本地没有的提交。应该先把远端的新提交抓下来，与本地分支整合，然后再推送。
通常的流程是：
git fetch origin— 获取远端最新对象，更新origin/main；- 整合：可以选择
git merge origin/main产生一个合并提交，或者git rebase origin/main重放本地提交（变基的细节将在下一篇展开）。最终目的都是让本地历史包含远端的提交； git push origin main— 整合完成后再次推送，此时远端处在历史子集位置，推送可以快进完成。
整合阶段可能产生冲突。例如本地修改了 src/index.ts，远端也有人改动了同一文件的同一行，Git 无法自动合并，会标记冲突：
$ git merge origin/main
Auto-merging src/index.ts
CONFLICT (content): Merge conflict in src/index.ts
Automatic merge failed; fix conflicts and then commit the result.此时需要手动编辑冲突文件，选择保留的版本，标记为已解决（git add <file>），最后提交合并结果。完成后再推送。
如果想保持线性历史，避免额外的合并提交，可以使用 git rebase。但这会让提交 ID 发生变化，对已经推送过的分支使用需格外谨慎。
常见协作工作流
远程仓库的存在支撑了几种不同的多人协作模式。以下是两个常见的工作流，涵盖了从简单项目到大型开源项目的实际需求。
功能分支工作流
这一模式在 GitHub 文档中被称为 GitHub Flow。核心规则是：
main（或master）分支始终保持稳定、可部署状态，任何人不直接在上面提交；- 每个特性、修复或实验放在独立的功能分支上开发；
- 功能分支完成后推送到共享仓库，创建一个 Pull Request（或 Merge Request）进行代码评审；
- 评审通过后，将分支合并到
main，然后删除功能分支。
开发过程示例如下：
bash
# 基于 main 创建功能分支
git checkout -b feature/oauth
# 开发并提交...
git commit -m "Implement OAuth flow"
# 推送功能分支到 origin 并建立跟踪
git push -u origin feature/oauth此时协作者在托管平台上可以看到该分支，并可以发起 Pull Request。评审期间如果还需要修改，只需在本地追加提交并再次推送；新提交会自动反映到同一个 Pull Request 上。合并完成后，切换到 main 执行 git pull 同步最新状态，之后可以删除远程和本地的功能分支。
功能分支工作流的优点是隔离性强：多个开发者分别在不同分支上工作，不会因为频繁向 main 合并而互相干扰。main 的更新频率降低，质量也更有保障——合并前至少经过一轮评审。
Forking 工作流
在开源项目或不希望外部贡献者直接推送的场景中，通常采用 Forking 工作流。贡献者不直接对共享仓库进行推送，而是：
- 在托管平台 Fork 上游仓库，生成完全由自己控制的个人远程副本；
- 将个人 Fork 克隆到本地：
git clone <fork-url>； - 添加上游仓库为另一个远程引用（通常取名
upstream）：git remote add upstream <上游仓库-url>； - 在本地创建分支，修改后推送到个人 Fork（即
origin），而非上游； - 在托管平台向上游仓库发起 Pull Request，等待维护者拉取。
bash
git clone https://github.com/my-user/node.git
cd node
git remote add upstream https://github.com/nodejs/node.git
# 开发
git checkout -b fix-typo
git commit -m "Fix typo in docs"
git push origin fix-typo
# 然后在 GitHub 上打开 PR，目标选择 upstream 的 main在 Pull Request 被接受之前，如果上游仓库有了新提交，还需要同步：
bash
git fetch upstream
git checkout fix-typo
git merge upstream/main # 或 rebase
git push origin fix-typo在这种模式中，origin 和 upstream 两个远程引用分工明确：origin 是写入口，upstream 用于拉取上游变更。贡献者的权限边界非常清晰——永远不会直接接触核心仓库。
注意点
- 远程地址可以使用 HTTPS 或 SSH。HTTPS 不需要额外配置，但每次推送可能要输入凭据；SSH 需要提前生成密钥并配置在托管平台。同一个仓库可以针对 fetch 和 push 使用不同协议，但一般保持一致。
git push origin local-branch:remote-branch可以把本地分支推送到不同名的远程分支，但这类映射会让协作变得混乱，应尽量避免。- 从 Git 2.27 开始，可以通过配置
pull.rebase为true让git pull默认执行变基。团队需要统一标准，否则各自产生的合并历史会截然不同。 - 推送前没有 fetch 是常见的失误。即使觉得本地工作是基于最新代码，实际上一两天未拉取就可能已经落后许多。养成推送前先
fetch再merge/rebase的习惯可以避免很多冲突。 - 远程跟踪分支不是本地工作分支，不要手动修改
refs/remotes/origin/main。它们只反映上次 fetch 时的远端状态，手动修改会导致校验失败。 git push --force会强制覆盖远端分支，可能使其他协作者的提交丢失。除非明确知道后果且与团队协调过，否则不要使用。更安全的变体是--force-with-lease，它会先检查远端状态是否与本地预期一致，不一致则拒绝覆盖。- 远程操作自然依赖分支与合并的基础（创建分支、解决合并冲突），但本篇不再重复展开。如果对合并冲突的处理还不熟悉，请参考前一章“分支与合并”。
参考链接
- [1] https://github.com/nodejs/node.git
- [2] https://docs.github.com/en/get-started/using-github/github-flow
- [3] https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models
- [4] [官方] 远程仓库协议：Git 远程仓库地址常用 HTTPS 或 SSH。 HTTPS 形式
- [5] https://docs.github.com/en/get-started/using-git/getting-changes-from-a-remote-repository
- [6] https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository