远程仓库Remote Repository
你可能会说
我的提交只在自己电脑上，怎么让别人也能看到？
位于另一处、可通过网络访问并与本地仓库交换提交的仓库你在本地提交了 B，GitHub 上的远程 main（origin）仍指向 A；提交只在本地，直到 push 把它发送到远程。之后同事可以基于远程历史提交 C；如果远程比本地多了提交，直接 push 会被拒绝。pull 会先 fetch，再按当前配置用 merge 或 rebase 集成远程提交。origin 只是常见的远程名称；推送到仓库不等于网页已经部署。
先知道
也常被叫作远程Remoteorigin
你可以这样告诉 AI Agent
请先 git fetch origin，再比较本地 main 与更新后的本地远程跟踪记录 origin/main。如果远程 main（origin）多了同事的提交 C，说明它改了什么，再用 git pull 按项目配置的 merge/rebase 方式集成并处理冲突。确认 C 的改动保留、页面检查通过后再推送；说明 push 只同步到远程，不代表网站已经部署。
什么时候用
- 用 git remote -v 查看当前仓库关联了哪个远程地址$ git remote -vorigin https://github.com/you/my-first-page.git (fetch)
- 克隆或初始化时把远程仓库命名为 origin，后续命令直接用它$ git remote add origin https://github.com/you/my-first-page.git克隆时通常已自动配好 origin
- push 被拒绝时先查看远程多出的提交，再 pull 并集成后推送git pull→git push→推送成功 ✓
- clone 会复制远程当时的提交，并默认把远程命名为 origin$ git clone https://github.com/you/my-first-page.gitCloning into 'my-first-page'...
什么时候不用
- 把密钥、密码或 .env 提交并推送到远程仓库.env 里写着密钥，推送后任何人都能拉到
- 推送被拒绝时直接强推覆盖远程历史git push --force 抹掉了同事刚推送的 3 个提交被拒绝时应先拉取合并，而不是强推
- 在错误的远程地址上推送，改动进入别人的仓库推送到了别人的仓库地址推送前用 git remote -v 确认地址
- 以为推送即上线：远程仓库不等于网站已经部署git push ✓→网站没更新
组成结构 · Anatomy
https://github.com/you/my-first-page.git
指向可通过网络访问的仓库；origin 只是常见名称，换名不改变仓库内容
常见变体 · Variants
查看远程remote -v
git remote -v
确认本地仓库关联了哪些远程地址
新增远程remote add
git remote add origin https://…
本地仓库还没有关联远程地址时
推送push
git push origin main
把本地提交送到远程仓库
拉取pull
git pull origin main
先 fetch 取回远程提交，再按配置 merge/rebase 集成本地历史
典型使用场景
本地提交 B 尚未发送到远程
共同起点：A
本地 main: A → B (HEAD)
远程 main（origin）: A
提交 B尚未发送
网页上的仓库仍停在 A
提交先进入本地仓库；只有 push 成功后，远程分支才会前进。
push 后两边都有 A、B
本地 main: A → B (HEAD)
远程 main（origin）: A → B
| 本地仓库 | 有 B |
| 远程 main（origin） | 有 B |
push 做了什么把可达提交发送到远程
同步到远程只表示代码提交可见；是否部署还取决于另一个部署流程。
同事提交 C 后，本地 push 被拒绝
本地 main: A → B (HEAD)
远程 main（origin）: A → B → C
| A | 本地 + 远程 |
| B | 本地 + 远程 |
| C · 同事的修复 | 远程；本地未取回 |
git push origin main
! [rejected] main (non-fast-forward)
远程包含你没有的 C，Git 拒绝这次直接推送以免覆盖对方历史。先查看并集成 C。
pull 后按配置集成 C 并复查提交
git pull origin main
本地 main: A → B → C (HEAD)
本地远程跟踪记录 origin/main: A → B → C
远程 main（origin）: A → B → C
pull 第一步fetch 取回远程提交
pull 第二步按配置 merge / rebase 集成
这个例子线性历史可直接前进到 C
先确认 C 的内容，再按项目的 pull 配置集成；保留同事提交后，本地与远程历史一致。
延伸阅读 · 权威出处
快速练习