git remote add origin 是在本地仓库中为远程仓库地址创建别名连接，仅修改 .git/config 文件，不校验地址有效性或触发同步。
本地仓库和远程仓库不是主从关系，而是对等副本关系；远程仓库只是被约定为“中心”来协作，并非权威源头。
git remote add origin 是在建立什么连接
它只是给一个远程仓库地址起个本地别名（比如 origin），不触发任何数据同步，也不校验该地址是否真实存在或可访问。
- 执行后只改写
.git/config文件，添加一段类似[remote "origin"] url = https://gitee.com/user/repo.git的配置 - 后续
git push origin main中的origin就是靠这个别名识别目标地址 - 可以添加多个远程别名（如
upstream、backup），每个都指向不同 URL - 如果 URL 写错或权限不足，真正出问题是在
push/pull时，而不是remote add阶段
克隆下来的项目为什么自动有 origin
因为 git clone 内部已执行了 git remote add origin <URL>，并默认把远程的 main（或 master）分支检出到本地 main，还设置了上游跟踪（upstream tracking）。
- 这意味着你运行
git pull或git push不带参数时，Git 默认操作的就是origin/main - 可通过
git branch -vv查看当前分支是否设置了 upstream，输出中会显示[origin/main] - 如果你删掉了
origin（git remote remove origin），再想恢复，必须重新remote add，clone 不会自动重装
git push 被拒绝的常见真实原因
不是“远程没权限”，而是本地与远程在同一条分支上产生了不可自动合并的提交历史分歧——最典型的是你本地 rebase 或 reset --hard 过，又没强制推送。
-
error: failed to push some refs to '...'后紧跟着! [rejected] main -> main (non-fast-forward)：说明远程main有你本地没有的 commit，而你的本地提交不是它的直接后代 - 解决方式不是删远程，而是先
git pull --rebase拉取并变基，或确认无误后用git push --force-with-lease（比--force更安全） - 如果远程是保护分支（如 GitHub 的
main开启了 branch protection），即使历史一致，也会因缺少 CI 通过、PR 审核等策略被拒——这时错误信息里通常带remote: error: GH006:或类似提示
fetch 和 pull 到底差在哪一行代码
就差在是否执行 git merge（或 git rebase）这一步。fetch 只下载对象和引用，pull 多做了“整合进当前分支”这件事。
-
git fetch origin：把远程所有分支的新 commit、新 tag 下载到本地.git/，但完全不动你的工作区和当前分支指针；你可以用git log origin/main看远程状态，再决定怎么处理 -
git pull origin main≡git fetch origin main+git merge FETCH_HEAD（默认）或git rebase origin/main（如果配置了pull.rebase=true） - 团队协作中建议养成先
fetch再手动merge/rebase的习惯，尤其在多人共用一个长期分支时，能避免意外覆盖他人刚推上去的提交
真正容易被忽略的是：远程仓库本身不保存工作区，它只是裸仓库（bare repo）；你看到的“远程分支”其实是你本地仓库里记录的对远程状态的快照（refs/remotes/origin/main），不是实时反射。每次 fetch 才刷新这个快照——所以别以为 git branch -r 显示的永远是最新的远程分支列表。
