- b8e · retry upload
- c2f · add upload state
- a1c · init
版本协作 · 版本协作
仓库Repository
Git 仓库分本地和远程：clone/fetch/push 在两边搬运提交，操作前看 ahead/behind，主分支走 PR 合并，密钥与大文件不进历史。
先认出本机文件夹和 origin，再决定能不能推
下面就是两只仓库盒子。默认还没 fetch；分叉时 push 会被拒，拒绝章盖在 origin 上；merge 后再推，两边指向同一提交。
第 0 步先打开：终端跑 git fetch 再看 ahead/behind。下面是本机文件夹和 origin 两只盒子。
ref 待 fetch · 可能有新提交
- a1c · init
还没看 origin
本地有 2 个提交待推。先 fetch，别直接 push。
原因：本地和远程是两份历史。下一步：fetch 看 origin，或看分叉时直接 push 会怎样失败。
知识点：两份历史
盒子上刚看到的 ahead/behind，这里只给命名。
- 本地仓库和远程 origin 是两份独立历史，不是同一块磁盘。
- fetch 只搬引用，不改工作区；push 才把本地提交发到远程。
- diverged 时默认拒绝非快进，先 merge 或 rebase 再推。
- main 通常受保护，走 PR；
.env用.gitignore挡在提交前。
什么时候用、怎么用
跨机器或跨人分享时才需要远程边界。
- 信号：要把提交给队友看、换电脑继续，或触发 CI。
- 最短路径：fetch → 读 ahead/behind → 分叉先 merge → push；受保护分支改走 PR。
- 不适用：纯本地草稿不必建远程；密钥不要靠远程仓库备份。
正反例：分叉时怎么推
同一目标——把本地提交推上 origin/main，只改一个选择。
队友的 d49 被保留，CI 跑在合并后的历史上。
origin/main 上的队友提交被抹掉，他人本地出错，共享分支禁用强推。
快速自测
本地做了提交，fetch 后发现队友也往 origin/main 推了新提交。直接 git push 通常会怎样？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。