企业官网建设流程全解析

很久以前我第一次把一个项目推到 GitHub，用的是最普通的 HTTPS 方式，每一次 push 都要输账号甚至还要复制个人访问令牌，项目少的时候还能忍，项目多了、提交频繁了，这个重复操作真的让人崩溃。后来切到 SSH 方案，一次性生成密钥、把公钥配置到 GitHub 上，之后不管是 push 还是 pull 都不需要再输任何凭证，体验完全不一样了。这篇我就把“上传项目到 GitHub 详细步骤(ssh)”从头到尾走一遍，不只给命令，还会解释每一步为什么要这么做，以及我实际用下来踩过的坑和常见报错的排查思路。适合刚接触 Git、想把自己的本地代码同步到 GitHub 的初学者，也适合那种明明照着教程做但偏偏推不上去、已经准备摔键盘的人对照排查。

1. 为什么选择 SSH：一次配置，长期免密推送

1.1 HTTPS 方式为什么那么难受

很多人一开始接触 Git 远程仓库，默认都是选 HTTPS 地址，因为看起来简单，复制下来就能用，也不需要什么密钥概念。理论上确实如此，但有个非常现实的问题：GitHub 早就不再允许直接用账号密码来 push 了，现在 HTTPS 方式要求你使用 Personal Access Token（个人访问令牌），也就是一串几十位的随机字符串，每次 push 的时候输一次。哪怕你把令牌保存在 Git 的凭据管理器里，换一台机器、重新系统，又得重新认证一遍。如果你有好几个 GitHub 账号，HTTPS 切换身份的体验更是痛苦。

当然，HTTPS 也有自己的优点：比如你只是想临时克隆一个公开仓库，不需要任何证书，一条git clone https://...就能搞定，而且公司的内网防火墙往往放行 443 端口，对 HTTPS 更友好。所以我并不是说 HTTPS 一无是处，而是对于“需要长期、频繁上传自己项目”的场景，SSH 显然是更舒服的那个选择。

1.2 SSH 身份认证是个什么原理

把 SSH 理解为门禁卡比较贴切。门禁卡里保存着一个身份标识，你在办公楼门口刷一下，系统核对无误就把门打开。SSH 密钥对则包含两个文件：私钥和公钥。私钥留在你自己的电脑里，绝不外传；公钥相当于你的门禁标识，可以公开，甚至可以直接贴在 GitHub 账户页面上。

当你执行git push连接 GitHub 时，GitHub 并不直接把你的公钥拿过来对比，而是发一串随机数据到本地，本地用私钥对这段数据进行“签名”，然后把签名结果提交给 GitHub，GitHub 再用你预先上传的公钥去验证这次签名是否匹配。因为只有持有对应私钥的人才可能生成这种有效签名，所以 GitHub 不需要知道你的私钥内容，也不需要保存任何本机密码，就完成了身份验证。这整个过程叫公钥加密与数字签名验证，虽然平时使用的时候感觉不到它的存在，但理解这一点对后面排查问题非常关键。

1.3 什么场景最适合 SSH 方案

根据我的实际体验，SSH 方案在下面几种情况里优势最大：

• 你有一台固定的开发电脑，每天都要频繁 push 代码；
• 你配置好了ssh-agent，开机后只需要解锁一次密钥，整个 session 内都免密操作；
• 你有多个项目分布在多个仓库，不用为每个项目单独记忆令牌；
• 你希望就算换电脑，也能快速恢复一套干净、可复用的连接方式。

如果你只是偶尔改一次公开项目里的几个文件，那用 HTTPS 加令牌也无可厚非。但既然要学 Git 上传，我建议直接一次到位，把 SSH 弄明白，后面所有项目都受益。这也是我写这篇内容最想传达的思路：不要用“能跑就行”的心态做技术选型，连接方式这种基础工程，值得一次配置好。

2. 准备工作：安装 Git 并完成全局配置

2.1 在你的操作系统上安装 Git

这一步如果你已经装好 Git，并且敲git --version能输出版本号，可以直接跳过。

不同系统安装方式不一样，我分别说一下我试过的做法：

Windows：最省事的是去 Git 官网下载安装包，安装时一路默认就行。也可以顺手把 Git Bash 装上，后面生成 SSH 密钥、跑 shell 命令都比在 PowerShell 里碰钉子要舒服。安装完打开 Git Bash，敲git --version，如果能显示类似git version 2.40.1.windows.1，说明成功了。

macOS：新机器上最快的方式是安装 Xcode Command Line Tools，直接终端输入xcode-select --install。装完 Git 也就有了。如果你用 Homebrew 比较熟，也可以brew install git，好处是版本通常会新一些。

Linux：Debian/Ubuntu 系用sudo apt install git，CentOS/RHEL 系用sudo yum install git或sudo dnf install git。装完同样先用git --version验证。

这里多说一句，不要在这步追求“最新版本”，能用就行。Git 的版本无非和分支策略、大文件支持这些周边功能有关，上传项目这种基本操作，任何近几年的版本都没问题。

2.2 设置全局用户名和邮箱

安装完 Git，第一件事是告诉 Git 你是谁。这一步不做，后面 commit 会失败，或者提交出来一堆乱七八糟的身份记录，非常难看。

git config --global user.name "你的名字或者昵称" git config --global user.email "你注册GitHub用的邮箱"

--global表示这台机器上的所有仓库统一使用这个身份。如果某个项目想用另一个身份，可以在那个项目目录里不加--global重新设置，就会覆盖全局配置。

设置完可以查看一下当前生效的配置：

git config --global --list

这里我踩过一次坑：用户名和邮箱和 GitHub 注册的不一致，push 上去之后，提交记录虽然能显示，但 GitHub 页面不会把它关联到你的账户头像上，看起来就像是一个陌生的 ID 在给仓库提交代码。尤其是用公司邮箱注册过 GitHub 又忘了的人，一定要回头检查这一项。

2.3 先看看本机是不是已经有 SSH 密钥

这一步经常被新手忽略。其实很多开发工具（比如某些 IDE、部署工具）在安装配置阶段已经帮你生成过一套 SSH 密钥了。如果你不做检查就重新生成一遍，反而可能把旧的覆盖掉，导致以前配好的连接全部失效。

检查方式很简单：

ls -la ~/.ssh/

如果目录下已经有id_ed25519和id_ed25519.pub或者id_rsa和id_rsa.pub这类的文件，说明本机已经有密钥对。其中后缀是.pub的是公钥，没有后缀的是私钥。优先复用已有密钥，这样最稳，不用重新去各个平台更新公钥。除非你能确定这套密钥来路不明或者已经泄露，再重新生成。

3. 生成 SSH 密钥：命令、参数与安全建议

3.1 密钥算法怎么选：ed25519 还是 RSA

GitHub 官方文档推荐的算法是 Ed25519，如果你没有历史包袱，直接用它：

ssh-keygen -t ed25519 -C "你的邮箱或者备注，比如 tom@example.com"

-t ed25519指定密钥类型，-C是注释，方便你在 GitHub 上识别这套密钥是从哪台机器来的。我一般习惯用邮箱+机器名，比如tom-macbook-pro。

为什么选 Ed25519？它生成的私钥和公钥都很短，安全强度却不亚于 RSA 4096，而且验证速度更快，目前几乎所有现代系统都支持。除非你用的是比较老旧的 Git 或 Linux 发行版，才需要退而求其次用：

ssh-keygen -t rsa -b 4096 -C "tom@example.com"

如果你不确定地形，优先 Ed25519 就好，真出了问题系统会报错，到时候再退到 RSA 也不迟。

3.2 生成过程的每一步提示都是什么

执行ssh-keygen -t ed25519 -C "..."以后，会陆续碰到几个交互提示，新手很容易在这里卡住不知道该不该回车。

第一条是 “Enter file in which to save the key”。意思是问你密钥文件放到哪个路径。直接回车表示使用默认路径~/.ssh/id_ed25519，我建议你全部默认，不折腾。自定义路径除了增加配置复杂度，没有任何实际好处。

第二条是 “Enter passphrase (empty for no passphrase)”。这是给私钥再加一层口令保护。很多教程直接让你留空，图省事。但我个人的建议是：如果你不需要高频自动部署，最好设置一个 passphrase。它的作用是就算有人拿到了你的私钥文件，没有口令也照样用不了。你可能担心每次 push 都要输一次口令很烦，这个后面用 ssh-agent 可以完美解决，解锁一次，整个 session 内都不用再输。

设置 passphrase 后系统会要求你再输入一次确认。全部完成，~/.ssh下就会出现两个文件：id_ed25519是私钥，id_ed25519.pub是公钥。

3.3 用 ssh-agent 管理私钥，避免反复输入口令

刚才说了，如果你设置了 passphrase，每次 push 都可能被要求输入一次。这时 ssh-agent 就派上用场了。

在 Git Bash（Windows）或者 Linux/macOS 终端里执行：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

第一条命令是启动后台的 agent 服务，第二条是把你私钥解锁后加载到 agent 里，执行时会提示你输入一次 passphrase。从那以后，当前终端 session 内再执行 git push/pull，Git 会从 agent 获取私钥签名，不会再追问口令。

Windows 用户如果用的是系统 OpenSSH 而不是 Git Bash 的 agent，也可以先在服务管理里把 “OpenSSH Authentication Agent” 服务启动并设为自动，然后在 PowerShell 里执行ssh-add。不过相对洋气，还是推荐直接在 Git Bash 里按上面两句走，简单顺手。

3.4 私钥管理的三条铁律

这里必须啰嗦几句，因为私钥泄露比 GitHub 账号被盗更难发现。平时我给自己定的规矩有三条：

1. 私钥文件永远只存在于自己可控的电脑里，不复制、不发送、不贴到云文档；
2. 发现电脑丢失或者私钥疑似泄露，第一时间登录 GitHub 删掉对应的公钥，并重新生成一套；
3. 不要图方便把私钥放到项目目录里，尤其是不要提交进 Git 仓库，否则一旦仓库公开，私钥就跟着裸奔了。

公钥是随便可以公开的，但私钥丢了就是身份丢了。GitHub 那边所有通过密钥的写操作，都默认是私钥持有者本人在操作。

4. 把 SSH 公钥配置到 GitHub

4.1 复制公钥内容，别复制错文件

你需要复制的是id_ed25519.pub的内容，不是私钥id_ed25519。复制方式各平台不太一样：

• Windows Git Bash 或 PowerShell：clip < ~/.ssh/id_ed25519.pub
• macOS 终端：pbcopy < ~/.ssh/id_ed25519.pub
• Linux 终端：cat ~/.ssh/id_ed25519.pub，然后手动选中复制。如果你想用剪贴板，Ubuntu 可以装xclip，命令是xclip -sel clip < ~/.ssh/id_ed25519.pub

公钥内容是一长串字符串，看着有点像乱码，开头一般是ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...这样的格式。复制的时候尽量一次复制完整，不要漏掉开头结尾的空格或换行。

4.2 在 GitHub 网页端添加公钥的完整路径

登录 GitHub 后，点击右上角头像，选Settings，然后在左侧菜单找SSH and GPG keys，点进去以后会看到New SSH key按钮。

点击后需要填两项：

• Title：给这套密钥起个名字，方便以后辨认是哪台电脑用的。比如我在公司电脑上会写office-windows，在家里的 Mac 上写home-macbook；
• Key type：一般选Authentication Key，这是最标准的 SSH 密钥用途。GitHub 还支持 Signing Key，那是给提交签名用的，和登录认证是两回事；
• Key：把刚才复制的公钥粘贴进去，别复制成私钥。

保存成功后，GitHub 会要求你输入一次账户密码确认，这是正常的。添加完成后，列表中会多出一条带有你的 Title 的密钥记录。

4.3 用ssh -T git@github.com验证连接是否打通

公钥配好之后，最激动人心的一步就是测试连接。在终端里执行：

ssh -T git@github.com

第一次连接通常会出现一段提示，问你是否认识这个主机、是否要信任主机的 key。这里输入yes回车就行。这个提示是 SSH 的 host key 校验机制，本质上是防止中间人攻击，别直接输no，否则连接会被中止。

如果一切正常，你会看到类似这样的输出：

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

看到Hi 你的用户名就说明 SSH 认证已经打通了。后面那句 “does not provide shell access” 是正常提示，GitHub 本来就不给你 shell 登录权限，不影响任何 Git 操作。

如果这里直接报Permission denied (publickey)，说明公钥和私钥没配对成功，或者 Git 没有用对密钥，这个问题我们放到第 7 章专门讲。

4.4 多个 GitHub 账号或自定义命名的密钥怎么处理

不过我其实留意到：使用默认路径直接操作是解决不了问题的办法之一。如果你有多个 GitHub 账号，比如一个工作账号一个私人账号，那本地就会存在多套密钥。这时候要对 SSH 配置文件下手：

在~/.ssh/config文件（没有就新建）里，给不同账号设置不同的 Host 别名，例如：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519 Host github-work HostName github.com User git IdentityFile ~/.ssh/id_work

设置完成后，工作账号的仓库远程地址就要写成git@github-work:用户名/仓库名.git，而不是默认的git@github.com:...。这一套在多人多仓库的开发场景里特别好用，等于给每个身份都挂上了对应的门禁卡。

5. 在 GitHub 上创建仓库并关联本地项目

5.1 创建仓库时的一个关键操作：不要顺手勾选初始化文件

很多人创建仓库时，习惯把Add a README file、.gitignore和Choose a license都勾上。对于新建项目、本地没有任何文件的情况，这样没问题，仓库一开始就有骨架。但如果你本地已经有一个写好的项目，想要把它完整推上去，这三个选项最好一个都不要勾。

原因是：如果你本地初始化过 Git，本地代码有自己的一套提交历史；GitHub 那边如果已经存在一个 README 文件，它就有了另一套提交历史。这两套历史在第一次git push时会因为“没有共同祖先”而无法合并，搞出一堆 forcing 操作，对新手特别不友好。想少折腾，就老老实实建一个空仓库，等本地代码推上去之后，再在 GitHub 网页端补充 README 或者说明文件。

别忘了选择仓库可见性。公开仓库任何人都能看，私有仓库只有你或者你邀请的协作者能看。除非你有意开源，否则个人项目建议先拿 Private。

5.2 拿到正确的 SSH 远程地址

仓库创建完成后，GitHub 会显示一个快速开始的页面，里面给出几种远程地址。一定看清楚，我们要的是 SSH 形式，看起来像这样：

git@github.com:用户名/仓库名.git

不是 HTTPS 形式：

https://github.com/用户名/仓库名.git

如果你复制错了，后面会陷入每次都要输入账号令牌的困境，那就失去 SSH 的意义了。页面上一般有 HTTPS、SSH、GitHub CLI 三个标签，需要自己点一下 SSH 标签，再去点复制按钮。

分支名也要注意，GitHub 新仓库默认主分支往往叫main，本地仓库如果还在用master，后面推送时会遇到分支匹配问题，我们下一节处理。

5.3 本地项目初始化和关联远程仓库

终端进入你的项目目录：

cd /path/to/your/project

如果这个目录还不是一个 Git 仓库，执行：

git init

执行后，目录下会多出一个隐藏的.git文件夹，它就是 Git 的本地版本库所在。然后把这个仓库和远程地址关联起来：

git remote add origin git@github.com:用户名/仓库名.git

这里的origin是远程仓库的默认别名，就相当于给“远程仓库地址”起了个短名字，以后你不用敲一长串地址，只需要说origin。

关联完可以用这个命令确认一下：

git remote -v

正常会显示两行，fetch 和 push 都指向同一个地址。如果之前已经用 HTTPS 关联过想换成 SSH，不需要删掉重加，直接改 URL 就行：

git remote set-url origin git@github.com:用户名/仓库名.git

不要用git remote rm origin再加，那样反而多一步，还容易误删其他配置。

6. 第一次推送与日常更新流程

6.1 提交前先处理 .gitignore，避免垃圾进仓库

很多人第一次上传项目，直接git add .把所有文件一股脑都加进去，结果把node_modules、.venv、target、__pycache__这些动辄几十万文件的东西全推上去了，要么 push 半天传不完，要么第三方库在 GitHub 上变成了巨大的垃圾仓库。

正确的习惯是在项目根目录创建.gitignore文件，把不需要版本控制的目录和文件忽略掉。下面是几个非常常见的忽略规则示例：

# 依赖目录 node_modules/ .venv/ venv/ # 构建产物 dist/ build/ target/ # 缓存 __pycache__/ *.pyc # 环境变量 .env .env.local # IDE 目录 .idea/ .vscode/

不写.gitignore就git add .，提交几百 MB 的东西上去，也是一种常见的“仓库糖尿病”。等推送卡死再回头清理，反而要花更多时间处理历史文件。

6.2 暂存文件和第一次提交

先把要上传的文件放进暂存区：

git add .

如果你只想提交某些文件，可以写成：

git add src/index.html docs/readme.md

然后提交：

git commit -m "feat: 初始提交"

提交信息建议写清楚这次提交干了什么。国内大部分项目习惯用前缀区分类型，比如feat代表新功能，fix代表修复缺陷，docs代表文档变更，chore代表杂项。这不是 Git 强制要求的，但对后续翻历史记录很有帮助。

提交前最好先看一眼状态：

git status

它会告诉你有哪些文件被暂存、哪些还没被跟踪，能有效避免提交错东西。

6.3 第一次推送：-u参数到底做了什么

第一次推送到远程仓库，命令是：

git push -u origin main

这里有两个细节值得展开。

第一，分支名。如果本地当前分支不是 main 而是 master，执行会报错或者推到一个错误分支。可以先看看当前分支：

git branch --show-current

如果是 master，而你的 GitHub 仓库期望 main，可以先把本地分支改个名：

git branch -M main

这样 Git 会把当前分支重命名为 main，并保留所有提交历史。

第二，-u是--set-upstream的简写，意思是把本地分支和远程分支建立“跟踪关系”。只要跑这么一次，以后在本地直接执行git push和git pull，Git 就知道你要和哪个远程分支对应，不需要再带参数了。很多教程讲不清楚这点，导致有人每次都敲一遍git push -u origin main。

第一次 push 成功后，GitHub 仓库页面就能看到你的项目文件了。

6.4 如果仓库创建时已经初始化了 README，怎么合并

万一你没听劝，建仓库的时候勾了 README，本地又已经有代码，第一次 push 大概率会收到这样的提示：

! [rejected] main -> main (fetch first)

这时候远程和本地就像是两条没有公共节点的线，需要先做一次合并。既然远程仓库只有一个 README，本地历史更完整，推荐用 rebase 方式拉取：

git pull --rebase origin main

然后再 push：

git push -u origin main

--rebase会把本地的新提交“叠”到远程的提交后面，这样历史是一条线，比默认的 merge 更干净，也不会产生额外的合并提交记录。如果 rebase 过程中提示冲突，那就打开冲突文件手动处理，解决完后再git add、git rebase --continue，最后写提交信息完成合并。

6.5 更新项目的三连操作，以及先 pull 后 push 的习惯

日常把新改动上传到 GitHub，其实就是三连操作：

git add . git commit -m "fix: 修复某问题" git push

如果只有部分文件需要提交，就明确写文件路径，而不是每次git add .。如果项目多人协作，或者你在两台电脑上交叉开发，push 之前最好先git pull --rebase，把远端可能的新提交先同步下来，避免本地直接 push 被远端拒绝。

我自己养成的一个习惯是：每次开工前先git pull，每次提交前看git status确认范围，推送前再检查一次提交信息是否准确。这个过程熟练之后不到十秒钟，却能避免大量返工。

7. 常见问题与排查实录

7.1 Permission denied (publickey)：九成是公钥没配对

这是 SSH 方案里最经典的报错，新手基本都会遇到。看到这个提示别慌，按顺序查三个地方：

第一步，确认密钥真的存在且是完整生成过的。执行ls ~/.ssh/，看看有没有一对密钥文件。如果你是从别的电脑复制来的密钥，还要检查文件权限，过于开放会被 SSH 拒绝使用。Linux/macOS 下可以执行：

chmod 600 ~/.ssh/id_ed25519

第二步，确认公钥真的添加到了 GitHub。重新走一遍第 4 章，复制.pub内容到 GitHub 的 SSH and GPG keys 页面。注意不要复制私钥，也不要在粘贴时多出空格或换行。

第三步，确认 ssh-agent 加载的私钥和你预期一致。执行：

ssh-add -l

如果输出The agent has no identities.，说明 agent 里没有密钥，重新执行ssh-add ~/.ssh/id_ed25519。

还有一个很容易被忽视的点：如果你配置过~/.ssh/config并且给 Host 起了别名，比如github-work，那么git push时用的密钥会由 config 决定。如果 config 写错了路径，Git 就会拿错误密钥去认证，结果自然是 Permission denied。可以临时用ssh -T git@github.com测试默认连接，如果默认连接成功，而某个仓库却失败，那多半就是 config 里的 Host 和仓库远程地址对不上了。

7.2 连接超时：ssh: connect to host github.com port 22: Connection timed out

这个和密钥无关，纯粹是 SSH 到 GitHub 的链路不通。常见原因有几个：当前网络到 GitHub 的 22 端口被防火墙拦了、代理配置有问题、或者 DNS 解析出问题。

GitHub 官方其实提供了 SSH over HTTPS 端口（443）作为备选方案。做法是在~/.ssh/config里加一段：

Host github.com HostName ssh.github.com Port 443 User git IdentityFile ~/.ssh/id_ed25519

然后继续用原来的远程地址git@github.com:用户名/仓库名.git。这个方案的核心作用是把 SSH 流量从 22 端口换到 443 端口，因为 443 端口通常会被防火墙放行。测下来只要链路本身通，能正常访问网络，这个方法一般就能解决端口被限制的问题。

如果换成这个配置之后执行ssh -T git@github.com依旧超时，那基本就是本地全局网络层面的问题，检查网关、DNS、代理工具，别一直怀疑 GitHub。

7.3 Could not resolve hostname github.com：DNS 解析失败

报错里出现Could not resolve hostname，说明你的电脑没法把github.com解析成 IP 地址。最直接的办法是换一个公共 DNS，比如8.8.8.8或者114.114.114.114，也可以先刷新本地 DNS 缓存再试：

• Windows 上执行ipconfig /flushdns
• macOS 上执行sudo dscacheutil -flushcache
• Linux 上执行sudo systemd-resolve --flush-caches（视发行版而定）

另外检查一下 hosts 文件是不是被人为改写过。有人装过一些工具后，会把 Github 相关域名强制指向某个固定 IP，时间一长那个 IP 失效，就会导致这种解析异常。本地 hosts 文件位置在 Windows 是C:\Windows\System32\drivers\etc\hosts，macOS/Linux 是/etc/hosts。如果里面有 github.com 的行但明显不通，先暂时删掉再测试。

7.4 fatal: remote origin already exists：远程别名冲突

执行git remote add origin git@github.com:用户名/仓库名.git时报这个错，说明这个仓库目录曾经初始化过或者已经加过 origin。解决办法是先看当前有哪些远程地址：

git remote -v

如果列出的是一个旧的或者错误的地址，直接原地替换：

git remote set-url origin git@github.com:用户名/仓库名.git

如果你就是想把整个远程关联清掉重新加，也可以：

git remote rm origin git remote add origin git@github.com:用户名/仓库名.git

不过多数情况用set-url就够了，删了重加有点脱裤子放屁。

7.5 推送大文件失败或者卡住不动

GitHub 对单个文件大小有 100MB 的软限制，超过 100MB 会直接报错，超过仓库建议大小也会警告。如果你项目里有视频、模型文件、非常大的打包文件，不要直接往普通 Git 仓库里塞。要么用.gitignore把这类文件排除掉，要么使用 Git LFS（Large File Storage）。

Git LFS 的基本用法是装好插件后，用下面命令指定哪些文件类型需要由 LFS 管理：

git lfs install git lfs track "*.mp4" "*.zip" git add .gitattributes git commit -m "chore: 配置 git lfs"

之后正常提交，大文件会由 LFS 在后台处理。这一步虽然会多学一个工具，但对实际项目维护来说非常重要。我就见过有人把几百 MB 的构建产物直接推上去，仓库膨胀到拉取都要一分多钟，最后只能花大力气清历史。

7.6 换电脑或者重装系统后，怎么恢复 SSH 配置

换电脑以后，最安全的做法是重新生成一对新密钥，然后把新公钥加到 GitHub，同时去 GitHub 的设置页面把旧公钥删掉。这样旧设备即使落入别人手里，也无法再访问你的仓库，属于一种主动的“权限回收”。

如果你不想重新生成，也可以把旧电脑上的~/.ssh整个复制到新电脑。但这样做有一个前提：你要能确认旧电脑的密钥从未泄露。否则不如直接重来，反正生成密钥也就一分钟的事。复制密钥的时候记得同时修正文件权限，Linux/macOS 下私钥和公钥的权限分别是 600 和 644，过宽松的情况下 SSH 客户端会直接拒绝加载。

我在实际使用中还有一个很小的习惯：新电脑配置好 SSH 后，第一件事就执行ssh -T git@github.com验证一遍，成功后再初始化第一个仓库做端到端测试。这个习惯能让我快速定位是网络问题、密钥问题还是 Git 配置问题，免得等真正要提交代码时才发现问题。

这套流程走下来，上传项目到 GitHub 已经不只是“会了”，而是变成了一件肌肉记忆级别的日常操作。真正踩过几次坑之后你会意识到，SSH 连接的核心不是命令本身，而是对密钥体系和 Git 配置的清晰认知。照着本文一步步做完，你的电脑以后就能稳定、免密、安全地往 GitHub 推送任何项目了。