遇见高中生上个月团队来了个新同学，装完 Git 后的第一句话是：“为什么我 git push 的时候一直让我输密码，我不想每次都输。”我问他用的是 HTTPS 还是 SSH，他一脸茫然。这样的场景我见过太多次了——很多人对 Git 远程仓库管理的理解，停留在“把代码传上去”这一步，对 origin 是什么、fetch 和 pull 有什么区别、SSH 和 HTTPS 认证怎么选，基本靠复制粘贴。这篇文章我打算把这些东西完整过一遍，从远程仓库的本质讲起，再到添加、查看、修改远程地址，日常的 clone/fetch/pull/push 协作链路，然后到免密配置和多账号管理，最后是高频报错排查。不管你刚接触 Git，还是已经被远程仓库问题折磨过一阵子，应该都能在这里找到对应的解法。
1. 先弄清楚：远程仓库和本地仓库到底差在哪
1.1 远程仓库不是“云备份”，而是团队协作的中枢
很多新手把远程仓库理解成“代码的云备份”，这个理解其实偏差很大。远程仓库在绝大多数情况下是一个裸仓库，也就是说它只有 Git 的对象数据库和引用（refs），没有工作目录和暂存区。你在本地编辑器里看到的项目文件，在远程仓库里是不存在的。你可以从 GitHub、GitLab 的 Web 界面看到文件树、提交历史、分支列表，但你没法在服务器网页上直接改文件然后提交——远程仓库不是给你直接编辑用的。
我用“公共公告板”来类比本地仓库和远程仓库的关系：本地仓库相当于每个人的笔记本，记录你个人的工作草稿和完整修改历史；远程仓库是团队共用的公告板，所有成员把已经完成、愿意公开的成果贴上去，再从公告板上取走别人贴的新内容。协作的流程就是：你写完代码，本地 commit（记到笔记本），然后 push（贴到公告板）；别人改了，pull（把公告板的新内容同步到本地）。想清楚这个模型，后面很多 Git 命令就不难理解了。
远程仓库在真实项目里承担三个角色。第一是多人协作的中枢，所有成员的提交通过 push 和 pull 在远程仓库汇合，这也是它叫 remote 的原因——它是相对你本地仓库而言的“远端仓库”。第二是权限控制的边界，谁可以读、谁可以写，由远程仓库的权限系统统一管理，本地 Git 本身没有完备的账号权限体系。第三是自动化任务的入口，持续集成、持续部署一般都会监听远程仓库的 push 事件，一旦有代码推上来，自动触发构建、测试、发布流程。这也是为什么“提交到远程”之后还有那么多后续动作。
1.2 远程仓库的三种主流形态，各自适合什么场景
托管平台是最常见的一种形态，GitHub、Gitee、GitLab.com 都属于这一类。优点是免运维、功能全，PR/MR、Issue、CI/CD 全都集成好了，适合开源项目和大多数中小团队。缺点也很明显：代码资产放在第三方平台上，对保密要求极高的团队需要在合规层面想清楚。
自建 GitLab / Gitea / Gogs 是第二种形态，部署在公司内网或自己的服务器上。适合对代码资产有严格保密要求的团队。自建最大的坑是运维成本，升级、备份、磁盘扩容、高可用都要有人管，小团队很容易被这些事拖住精力。
第三种是最轻量的方案：在一台服务器上执行 git init --bare repo.git，然后通过 SSH 或本地路径访问。它适合个人多设备同步或者极少数人的小项目。缺点是没有任何 Web 界面、没有权限体系、没有 Code Review 流程，一旦团队超过两三个人，管理成本会急剧上升。我自己的经验是，除非只是临时用一下，否则不要长期依赖裸仓库方案。
1.3 远程仓库的引用结构，理解一半 Git 疑难杂症
在你的本地仓库 .git 目录里，除了 objects（对象数据库）、refs/heads（本地分支）、refs/tags（标签），还有一个重要部分：refs/remotes。用 git branch -r 看到的就是这些远程跟踪引用，比如 origin/main、origin/develop。这些引用记录的是“我上次和远程仓库通信时，远程分支指向哪个 commit”。
这个机制特别关键：远程跟踪引用只在 fetch、pull、push 的时候更新，你本地 commit 再多，也不会自动影响 origin/main。Git 是分布式的，它永远不会主动去连远程仓库，那会慢到无法接受。所以，你在 git status 里看不到远程有人提交的新内容，是正常的，origin/main 只是你本地缓存的远程快照。
一个非常经典的误解是“origin/main 一定等于远程仓库分支的最新状态”。实际上，如果你很久没 fetch，它可能早就过期了。遇到“远程分支为什么少了一个提交”这种问题，第一件事永远是先 git fetch 再看数据，别怀疑别人删了提交。同样的道理，你 push 到远程之后，远程分支在服务器上更新了，但你自己本地分支的跟踪信息也要通过 push 或者 fetch 来刷新。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从零连接：添加、查看、改址、删除远程仓库的完整姿势
2.1 添加远程仓库：git remote add 命令的完整参数
假设你新建了一个项目，本地已经 git init 并产生了一个或多个提交，现在要把代码推到远程。远程仓库你已经在 GitHub 或 GitLab 上建好了，记住一点：创建远程仓库时最好什么都别勾选，不要自动生成 README、.gitignore 或 license。这样你本地 push 上去时，两端历史是一致的，不会有“unrelated histories”的麻烦。
添加远程仓库的命令是：
bash复制git remote add origin https://github.com/username/repo.git
这里的 origin 是远程仓库的别名，也是 Git 世界里的默认约定。它不是强制规定，你完全可以用其他名字，但团队里大家都默认用 origin，沟通成本最低，所以我建议你跟着约定走。URL 有几种常见形式：
- HTTPS：
https://github.com/username/repo.git - SSH：
git@github.com:username/repo.git - 本地路径：
/srv/git/repo.git
如果你想确认别名和 URL 是否配好了，用 git remote -v。-v 会同时显示 fetch 和 push 两个 URL，正常情况下两者一致。少数场景下你可以让 fetch 和 push 指向不同地址，比如拉取用只读地址、推送用可写地址，但日常工作中保持同一个 URL 最省心。
2.2 修改远程地址：set-url 解决仓库迁移和协议切换
git remote set-url 这个命令很多人平时用不到，但一旦用到就是救命的。最常见的场景是仓库迁移。团队把代码从 GitLab 迁到 GitHub，或者换了服务器地址，你不需要重新 clone，只需要改一下远程 URL：
bash复制git remote set-url origin git@github.com:username/repo.git
另外一种常用场景是切换协议。比如你最初 clone 用的是 HTTPS，每次 push 都要输密码，后来决定换成 SSH 免密，那只需执行上面这条命令，把 URL 换成 SSH 形式即可。改完之后用 git remote -v 验证一下，最好再执行一次 git fetch，确认还能正常通信。
这里有个容易踩的坑：如果你改了远程 URL，但是本地分支的上游跟踪地址还是旧的，某些操作会提示 “The upstream branch of your current branch does not match the name of your current branch”。这种提示一般不影响 push/pull，因为 Git 会按分支名去匹配新的 origin，但看到提示时别慌，它只是提醒你上游跟踪信息需要清理。
2.3 重命名和删除远程仓库，别让残废配置拖后腿
重命名远程仓库用 git remote rename old-name new-name。比如你想把默认的 origin 改成 upstream，执行 git remote rename origin upstream 即可，本地对远程跟踪引用的引用也会一并更新。
删除远程仓库用 git remote remove origin。这个命令只会删除本地的远程配置，不会动远程服务器上的仓库。删完之后你本地分支的上游跟踪关系会变成“无”，下次 git push 时提示你指定远程分支。用 git branch -vv 能看到跟踪关系，如果显示 [origin/main: gone]，说明本地分支曾经跟踪的远程分支已经被删掉或配置被清掉了。
说实话，日常开发中“删除远程仓库配置”这个操作不太常用，但我在给团队做 Git 培训时经常看到有人因为 clone 了一个仓库，然后又想把它的远程地址改成自己 fork 的地址，结果没有先 remove 掉原来的 origin，直接 add 报错。这时候记住一个顺序：先 git remote remove origin，再 git remote add origin 新地址，一步到位。
2.4 首次推送：-u 参数到底在做什么
本地代码要推到远程，首先要保证当前分支名符合预期。现在很多人习惯用 main 而不是 master，可以用这条命令重命名当前分支：
bash复制git branch -M main
然后执行首次推送：
bash复制git push -u origin main
-u 是 --set-upstream 的简写，作用是把当前本地分支和远程分支 origin/main 建立跟踪关系。建立之后，下次直接输入 git push 或 git pull，Git 就知道要推送到哪里、从哪里拉取，不需要每次都带参数。这是最容易忽略、也最值得理解的一个参数。
第一次 push 前还有一件重要的工作：检查 .gitignore。很多初学者把 node_modules/、target/、.idea/ 等文件推上去了，结果仓库变得无比臃肿。如果已经发生，可以用 git rm -r --cached node_modules 把它们从版本控制中移除，但保留本地文件，然后重新 commit。另外，.env 这类环境变量文件一定不能提交，里面经常藏着密码和密钥，一旦推到远程仓库并公开，基本等于泄露。
3. 日常协作主循环：clone、fetch、pull、push 一条链路讲透
3.1 clone：它不只是“把代码下载下来”
git clone 是入门 Git 接触的第一个远程仓库命令。很多人以为它只是把文件下载下来，其实它的底层做了四件事：在本地创建新目录、初始化一个 Git 仓库、把远程仓库的所有对象拉取到本地、把默认分支检出到工作区。所以 clone 之后你拿到的是一个完整的仓库历史，而不只是一堆当前文件。
基础用法是：
bash复制git clone git@github.com:username/repo.git
git clone git@github.com:username/repo.git my-directory
如果你想更快地拉取大型仓库，可以用 --depth=1 做浅克隆，只取最近一次提交。这在 CI 环境或临时查看代码时很实用，但要注意，浅克隆之后你无法完整查看历史，某些依赖完整历史的操作也可能受限。另外，clone 私有仓库时必须通过认证，HTTPS 方式可能需要输入用户名和 token，SSH 方式则要求你已配置好 SSH Key。
clone 完成后，本地会自动把远程分支记录下来。用 git branch -r 能看到 origin/main 这样的远程跟踪引用，用 git branch -vv 能看到本地分支和远程分支的对应关系。这些是理解后续 fetch、pull 行为的基础。
3.2 fetch 和 pull 的差别，一张表看清
git pull 是 git fetch 和 git merge 的合体。这句最简单也最容易被忽略的话，其实是很多人搞混 pull 和 fetch 的根源。
| 操作 | 更新本地远程跟踪引用 | 修改工作区/当前分支 | 常见使用场景 |
|---|---|---|---|
| git fetch | 是 | 否 | 先看看远端变化，再决定怎么合并 |
| git pull | 是 | 是（merge/rebase） | 直接同步最新代码到当前分支 |
举个例子。你正在 main 分支开发，同事推了一个提交到远程。你执行 git fetch 之后，本地的 origin/main 会更新到同事提交的位置，但你的工作区文件没有任何变化，本地 main 分支还停在你原来的位置。此时你可以做任意对比和分析，比如：
bash复制git log --oneline HEAD..origin/main
这个命令能列出远程有、但本地没有的提交。看完之后，你可以决定是 git merge origin/main 把远程提交合并过来，还是先处理手头事情再说。
git pull 一步到位，但风险在于它把“取回数据”和“合并数据”绑在了一起。如果恰好当前工作区有未提交的修改，而远端改动的文件和你本地修改的文件重叠，pull 就会直接报错或者自动合并出冲突。所以我有个工作习惯：如果需要同步代码，先 git fetch，看一眼远端改了什么，再决定怎么合。等熟练了，再把 git pull --rebase 当作日常同步首选。
3.3 push 被拒绝怎么办：non-fast-forward 的全流程解法
push 遇到 rejected 是远程仓库协作里最常见的报错之一。错误信息大概长这样：
bash复制! [rejected] main -> main (non-fast-forward)
error: failed to push some refs
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
原因很简单：远程分支有别人提交的 commit，你的本地分支历史里没有包含这些提交。Git 为了不覆盖掉别人的工作，拒绝了这次推送。想硬推当然有办法，比如 git push --force，但那会把远端分支整个覆盖，属于极其危险的操作，团队协作时几乎没有正当理由直接强推。
正确解法分三步。第一步，拉取远端最新代码：
bash复制git pull --rebase origin main
--rebase 的意思是把你本地新提交的 commit 从远端分叉点处“摘下来”，重新接到远端 main 的最新提交后面，让历史保持线性。这样做的好处是干净，不会产生多余的 merge commit。第二步，如果 rebase 过程中出现冲突，Git 会停下来标出冲突文件，你需要手动编辑解决冲突，然后：
bash复制git add 冲突文件
git rebase --continue
第三步，重新推送：
bash复制git push
如果你实在不想用 rebase，也可以 git pull origin main 合并远端改动，再 push。merge 和 rebase 的对比后面会细讲，但先说结论：你自己的未推送分支，用 rebase 最清爽；已经推送到公共分支的提交，绝不要用 rebase 去改写，否则会坑到所有拉过这个分支的人。
3.4 合并策略选择：merge 保留真实，rebase 保持线性
同一段代码同步，到底是 merge 还是 rebase，团队里经常吵得不可开交。我的看法是：没有绝对正确，只有适不适合场景。
merge 会产生一个合并提交，把两条分支的历史交叉点记录下来。优点是保留了真实的分支结构，谁在什么时候从哪个分支合入，一目了然。缺点是历史会比较乱，合并提交多，看图复杂。
rebase 把当前分支的提交“平移”到目标分支的最新提交之后，得到一条线性的提交历史。优点是干净、简洁，方便 code review 和 git bisect。缺点是你改写了提交顺序和 commit hash，如果这些提交已经被别人 pull 过，后面就会产生各种冲突。
我的个人建议是：功能分支在合入主分支之前，用 rebase 把自己分支上的提交整理得干干净净；主分支上的历史用 merge 提交记录真实时间线。团队内部最重要的是一条统一的约定，比如在 GitLab/GitHub 上开 MR/PR 时选择 “merge commit” 或者 “rebase and merge”，这些平台设置都会影响最终历史形状。你要是还没主意，先在本地配置里定下 pull 的默认行为：
bash复制git config --global pull.rebase false
false 就是默认 merge，true 是默认 rebase。团队约定是什么，就配置成什么，别让每个人自己凭心情选择。
4. 免密配置：HTTPS 凭据与 SSH Key 两条路线怎么选
4.1 先搞清楚，Git 本身并没有账号系统
为什么每次都输密码？这得从 Git 的认证机制说起。Git 自己不带账号体系，它只是把 HTTP 和 SSH 的认证方式拿来用。你每次 push 时输的“账号密码”，其实是远程托管平台在验证你的身份。所以“免密”问题的本质是：如何让 Git 自动完成认证，而不是每次手动提供凭据。
有三种常见做法：一是配置 Git 凭据管理器，让系统代为保存 HTTPS 凭据；二是改用 SSH 协议，用公钥认证免密；三是使用平台提供的 Personal Access Token 代替密码。你应该根据自己的操作系统和使用场景选择，而不是盲目复制网上的方案。
如何确认当前项目用的是哪种协议？一条命令就够了：
bash复制git remote -v
URL 以 https:// 开头就是 HTTPS，以 git@ 开头就是 SSH。两条路线的选择和配置方式完全不同。
4.2 HTTPS 免密：凭据管理器和 Token 的正确打开方式
如果你走 HTTPS，最简单的方式是启用 Git 的凭据管理器。在 Windows 上，安装 Git for Windows 时会附带 Git Credential Manager，第一次 push 输入账号密码后，凭据会被保存在 Windows 凭据管理器里，之后自动使用。macOS 上对应的是 osxkeychain helper。你可以检查当前配置：
bash复制git config --get credential.helper
输出可能是 manager、osxkeychain 或 cache。如果是 cache，默认只缓存 15 分钟；如果是 store，会把明文密码保存到家目录下的 .git-credentials 文件里。store 虽然方便，但明文存储有泄露风险，不建议在生产环境电脑上使用。
现在 GitHub、Gitee、GitLab 基本都不支持直接用账号密码 push 了，而是要求使用 Personal Access Token。以 GitHub 为例，在 Settings → Developer settings → Personal access tokens 里生成一个 token，权限按需勾选，比如只勾 repo。使用时把 token 粘贴到密码输入框即可，用户名填你的 GitHub 用户名。Token 本质是一串携带权限的密钥，泄露了同样危险，所以别提交到仓库里。
4.3 SSH Key 免密：从生成到配置的一条龙
SSH 是很多开发者的最终选择，我也更推荐它。原理是：本地生成一对公私钥，公钥上传到远程托管平台，私钥保存在本地。推送时 SSH 协议用私钥签名，远程用公钥验签，两者配对成功就授权通过。
生成密钥的命令：
bash复制ssh-keygen -t ed25519 -C "你的邮箱" -f ~/.ssh/id_ed25519
-t ed25519 指定算法，是目前安全性和性能都较好的选择；-C 是备注，用来标记这个 key 属于谁；-f 指定生成的文件名，不指定的话默认就是 ~/.ssh/id_ed25519。执行过程中会提示你设置 passphrase（密钥口令），可以设置也可以留空。设置了 passphrase，每次用完私钥还需要输一次口令，配合 ssh-agent 可以省去重复输入，安全性更高。
生成后查看公钥：
bash复制cat ~/.ssh/id_ed25519.pub
把输出内容复制下来，添加到 GitHub 的 Settings → SSH and GPG keys、Gitee 的设置 → SSH 公钥、或者 GitLab 的用户设置页面。添加完成后验证：
bash复制ssh -T git@github.com
如果看到类似 Hi username! You've successfully authenticated 的输出，说明配置成功。然后把项目远程 URL 切换到 SSH 地址：
bash复制git remote set-url origin git@github.com:username/repo.git
这样就再也不用手动输密码了。
4.4 多账号多 key：用 ~/.ssh/config 按域名指定密钥
很多开发者有多个账号：个人 GitHub、公司 GitLab、可能还有 Gitee。每个平台每个账号如果要用不同的 SSH key，默认的 ~/.ssh/id_ed25519 就不够用了。解决办法是编辑 ~/.ssh/config：
code复制Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519
Host gitlab.company.com
HostName gitlab.company.com
User git
IdentityFile ~/.ssh/id_ed25519_work
它的作用很简单：当 SSH 连接哪个 Host 时，使用对应的 IdentityFile 私钥。这里有个常见的坑：同一个域名下有两个账号时，光靠域名无法区分两个账号，因为 SSH 本质上只认 key。解决方法是用 SSH 别名：
code复制Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
这时 clone 地址要写成 git@github-work:username/repo.git 而不是 git@github.com:...。这样 Git 会通过别名找到对应的私钥，从而以工作账号身份访问 GitHub。很多人在这一步卡了很久，其实就是没理解 SSH 别名的作用。
4.5 也别忽略 ssh-agent 的作用
有些人配好了 key，也把公钥传上去了，但 push 时还是提示 Permission denied。这时候检查一下 ssh-agent 是否加载了正确的私钥：
bash复制ssh-add -l
如果列表为空，把私钥加进去：
bash复制ssh-add ~/.ssh/id_ed25519
ssh-agent 是一个驻留在后台的认证代理，用来帮你保存已解锁的私钥。在 macOS 上，钥匙串可以记住 passphrase，基本上设置一次，之后就不用再输入。在 Windows 上，Git Bash 的 ssh-agent 需要手动启动，不过现在 Git for Windows 也提供了自动启动选项，安装时可以留意。
还要提醒一句：SSH 和 HTTPS 混用是很多人踩过的坑。你配好了 SSH key，但项目 remote URL 还是 HTTPS 地址，push 当然还会要密码。检查 git remote -v，如果 URL 是 https:// 开头，就按前面讲的方式改成 SSH 格式。
5. 远程分支与协作规范：让团队不再互相踩脚
5.1 远程跟踪分支：本地分支和远程分支的“座机号”
本地分支和远程分支不是同一个东西。远程分支的实际状态存在服务器上，本地看不到；本地能看到的是远程跟踪引用 origin/main，它只是你上次通信时的快照。用 git branch -r 查看所有远程跟踪分支，用 git branch -vv 可以同时看到本地分支和它们跟踪的远程分支。
如果你想让当前本地分支跟踪远程分支，可以用：
bash复制git branch -u origin/main
这会在当前分支和 origin/main 之间建立跟踪关系。建立后 git push、git pull 不带参数时，Git 就知道该跟谁同步。很多新手直接用 git checkout origin/main 进入“游离 HEAD”状态，然后发现提交无处安放，就是因为没理解本地分支和远程分支的界限。
5.2 推送、删除、清理远程分支的正确方式
推送一个新分支到远程：
bash复制git push origin feature-login
这条命令会在远程创建一个同名分支，并设置本地分支跟踪它。如果你希望本地分支名和远程分支名不同，可以这样：
bash复制git push origin feature-login:feature-remote
删除远程分支：
bash复制git push origin --delete feature-old
删除后，你本地的 origin/feature-old 远程跟踪引用不会立刻消失。如果长期不清理，git branch -r 会显示一堆早已不存在的远程分支，误导你。清理命令：
bash复制git fetch --prune
或者：
bash复制git remote prune origin
这两个命令会把本地已经失效的远程跟踪引用删掉。我建议每周至少执行一次 git fetch --prune，让本地仓库的远程状态保持干净。
5.3 提交信息规范：审代码的人不需要猜
远程仓库管理不只是命令操作，还包含提交规范。我见过太多这样的提交信息：update、fix bug、111。等三个月后回看历史，根本不知道当时改了什么。养成写规范提交信息的习惯，收益远大于成本。
一个通用且常用的规范是 Conventional Commits：
feat: 新增用户注册接口fix: 修复登录态过期未跳转的问题docs: 更新 API 文档refactor: 重构订单查询逻辑test: 补充支付接口单测chore: 更新依赖版本
如果某个改动比较大，可以在冒号后面加一个描述性标题，然后用正文补充细节。规范提交信息的价值主要体现在三个地方：自动生成 changelog、用 git bisect 定位引入问题的提交、以及 Code Review 时不用打开代码就能大概知道改动意图。
5.4 分支保护与 MR/PR 流程
团队协作中，主分支一般是受保护的。在 GitHub 的 Settings → Branches → Branch protection rules 里可以设置：main 分支不允许直接 push、必须通过 PR 合并、必须至少一个 review 通过、必须通过 CI 检查。Gitee 和 GitLab 也有类似功能。
为什么需要保护？因为 shared main 分支如果谁都能直接推，一次不规范的提交就可能把主分支搞挂。更合理的流程是：从 main 拉出一个功能分支，在功能分支上开发、提交，push 到远程后创建 Merge Request / Pull Request，经过 review 和 CI 检查后由管理员合并进 main。
对于开源项目，通常采用 fork 模式：贡献者没有原仓库的写权限，只能 fork 到自己账号下，在 fork 仓库里开发，再向原仓库提交 PR。这种模式对远程仓库的管理要求和团队内部完全不同，但核心逻辑是一样的：以 remote 为边界，以 PR/MR 为代码合入的唯一通道。
6. 高频报错排查：远程仓库的坑我基本都踩过
6.1 “git 不是内部或外部命令”怎么办
这是 Windows 上最常见的入门问题，本质就是系统找不到 git 可执行文件。安装 Git for Windows 时，安装包默认会配置 PATH，但如果安装时取消勾选相关选项，或者电脑 PATH 被某些软件篡改过，就会出现这个报错。
解决办法分两步。第一步，确认 git 真的装好了，在开始菜单里打开 Git Bash，运行 git --version，能输出版本号说明安装正常。第二步，把 Git 的 cmd 目录加到系统环境变量，常见路径是 C:\Program Files\Git\cmd。加完之后重开一个命令窗口，git --version 就应该能识别了。如果你的命令行工具是 PowerShell，安装完 Git 后直接使用 Git Bash 也是不错的选择，省去不少环境变量问题。
6.2 “fatal: not a git repository” 排查链路
这个报错很唬人，但原因通常很简单：当前目录不是 Git 仓库，或者不在仓库的子目录里。Git 在执行命令时会向上逐级查找 .git 目录，如果在当前目录及所有父目录里都找不到，就报 not a git repository (or any of the parent directories): .git。
常见场景有三种。一是忘记 cd 到项目目录，直接在桌面或用户目录敲 git 命令；二是项目根本没执行过 git init，或者 clone 操作被人为中断；三是误删了仓库根目录下的 .git 文件夹。排查时先 ls -a（Windows 下用 dir /a）看看有没有 .git 目录，确认自己确实在仓库根目录或子目录里，再继续操作。如果 .git 被删了，那你本地历史基本就丢了，只能从远程重新 clone，这也是我一直强调不要乱删 .git 目录的原因。
6.3 “remote origin already exists”
这个报错在 git remote add origin xxx 时出现，意思是说当前仓库已经有一个叫 origin 的远程仓库配置了。要么你之前已经添加过，要么 clone 的仓库自带 origin。解决方案很简单：先删掉旧配置再添加，或者直接用 set-url 改地址：
bash复制git remote remove origin
git remote add origin git@github.com:username/repo.git
如果你只是想把地址换成新的，用 git remote set-url origin 新地址 更直接，不用反复删加。
6.4 “Permission denied (publickey)” 排查链路
这个 SSH 报错出现的频率极高，特征是你 push/pull 时被拒绝，提示公钥认证失败。排查我都按照这个链路走：
第一步，确认 URL 是 SSH 形式。git remote -v 看一下，如果是 https:// 开头，那这个报错可能不是来自 SSH，而是密码或 token 问题。第二步，确认 SSH agent 里有正确的 key：
bash复制ssh-add -l
如果提示 The agent has no identities，用 ssh-add ~/.ssh/id_ed25519 加进去。第三步，确认公钥已经上传到平台。第四步，用 SSH 详细日志看问题：
bash复制ssh -vT git@github.com
这个输出会明确告诉你用了哪个 key、服务器有没有接受它。第五步，在 Linux 上检查 ~/.ssh 目录权限，私钥必须是 600，目录必须是 700，权限太宽松 SSH 会直接拒绝读取。
如果还解决不了，考虑是不是多账号时用错了 key。检查 ~/.ssh/config 里为对应 Host 指定的 IdentityFile 是否正确，重点看我前面提到的别名机制。
6.5 “failed to push some refs”，远程分支领先于本地
这个报错前面已经讲过了，这里只强调排查思路。收到这个提示，说明远端有本地没有