卷积神经网络与滚动轴承故障诊断：从时频图到特征可视化
2026/9/19 11:21:34
1. 克隆之前先想清楚：你到底需要哪种方式
很多人第一次接触 Git 的时候，脑子里只有一个模糊的念头——“我要把 GitHub 上的代码弄到本地”。于是随手搜一条命令，复制粘贴，能跑通就完事。但真到了团队协作、多仓库管理、CI 流水线配置这些场景，才发现当初随手选的方式埋了不少雷。比如用 HTTPS 克隆的私有仓库，每次推送都要输账号密码；比如 SSH 密钥配错了位置，死活连不上；再比如公司网络对 GitHub 的访问时好时坏，克隆到一半断掉，重来又得从头下载。
这篇文章就是要把“git 克隆 GitHub 项目到本地”这件事彻底讲透。三种主流方式——HTTPS 克隆、SSH 克隆、GitHub CLI 克隆——它们各自适合什么场景、配置过程中有哪些容易忽略的细节、遇到问题怎么排查，我都会结合自己踩过的坑一一展开。无论你是刚装完 Git 的新手，还是已经用了几年但一直“知其然不知其所以然”的老手，都能从中找到对自己有用的部分。
先说一个基本认知：克隆（clone）不只是“下载代码”。它做的是把远程仓库的完整历史记录、所有分支引用、标签一并拉到本地，并在本地建立一个名为origin的远程追踪。这意味着你拿到的不只是当前最新的一份快照，而是整个项目的演进脉络。理解了这一点，你就能明白为什么克隆一个大型仓库会那么慢——它拉的是全部历史，不是单个版本。
那三种方式的本质区别在哪？简单说：HTTPS 走的是账号密码（或 token）认证，SSH 走的是密钥对认证，GitHub CLI 则是在前两者之上封装了一层更友好的交互。认证机制不同，决定了它们在不同场景下的优劣。下面逐个拆解。
2. HTTPS 克隆：最省事但也最容易踩认证的坑
2.1 一条命令背后的完整流程
HTTPS 克隆的命令长这样：
git clone https://github.com/用户名/仓库名.git看起来简单，但这条命令执行时，Git 在背后做了好几件事。首先它通过 HTTPS 协议向 GitHub 发起请求，拿到仓库的引用列表（refs）；然后根据引用列表把所有对象（commit、tree、blob）打包传输到本地；最后在本地创建.git目录，写入配置，检出默认分支的工作区文件。
对于公开仓库，这一步不需要任何认证，直接就能拉下来。这也是为什么很多教程推荐新手先用 HTTPS——门槛最低，装完 Git 就能用。
但一旦涉及私有仓库，或者你想往公开仓库推送代码，认证问题就来了。早期 GitHub 支持直接用账号密码，后来改成了个人访问令牌（Personal Access Token，简称 PAT）。如果你还用老方式输密码，会直接报错：
remote: Support for password authentication was removed on August 13, 2021.这个报错我见过太多次了，尤其是帮别人排查问题时。很多人以为是网络问题，其实是认证方式变了。
2.2 令牌的生成与缓存策略
生成 PAT 的路径在 GitHub 网页端的 Settings → Developer settings → Personal access tokens。你可以选 fine-grained token（细粒度，可以限定只对某个仓库有权限）或者 classic token（经典版，权限范围更粗）。对于日常开发，我建议用 fine-grained，最小权限原则，万一泄露了影响面也小。
生成之后，克隆私有仓库时这样用：
git clone https://用户名:令牌@github.com/用户名/仓库名.git但把令牌明文写在 URL 里很不安全，会留在 shell 历史记录和.git/config里。更好的做法是让 Git 帮你缓存。在 Linux/macOS 上：
git config --global credential.helper cache git config --global credential.helper 'cache --timeout=3600'这样第一次输入后，一小时内不用重复输入。Windows 上装 Git for Windows 时通常会自带Git Credential Manager，它会弹出一个浏览器窗口让你登录 GitHub，然后自动管理令牌，体验比手动输入好很多。
注意：如果你在
.git/config里已经写入了带令牌的 URL，记得手动改回干净的 URL，否则令牌会一直留在配置文件里。
2.3 HTTPS 方式的适用边界
HTTPS 最大的优势是穿透性好。绝大多数网络环境都允许 443 端口的 HTTPS 流量，不需要额外开放端口。在公司内网、学校网络、公共 Wi-Fi 下，HTTPS 通常都能正常工作。
但它的劣势也很明显：认证配置相对繁琐，令牌有有效期（可以设永不过期，但不推荐），而且每次换机器都要重新配置。对于个人偶尔拉几个公开仓库的场景，HTTPS 完全够用；但如果你是每天都要和私有仓库打交道的开发者，SSH 会更省心。
还有一个容易被忽略的点：HTTPS 克隆大型仓库时，如果网络中断，git clone默认不会自动续传，得从头再来。这时候可以用浅克隆减少数据量：
git clone --depth 1 https://github.com/用户名/仓库名.git--depth 1表示只拉最近一次提交，历史记录被截断。适合你只关心最新代码、不需要追溯历史的场景。后续如果需要完整历史，可以用git fetch --unshallow补回来。
3. SSH 克隆：一次配置，长期省心
3.1 密钥对的工作原理
SSH 克隆的核心是非对称加密。你本地生成一对密钥：私钥（private key）留在自己机器上，公钥（public key）上传到 GitHub。克隆时，GitHub 用公钥加密一段挑战信息，你的本地 SSH 客户端用私钥解密并回应，验证通过就建立连接。
生成密钥对的命令：
ssh-keygen -t ed25519 -C "你的邮箱@example.com"这里推荐用ed25519算法而不是传统的 RSA。ed25519 密钥更短、生成更快、安全性也足够。如果你有特殊兼容性需求（比如某些老旧的服务器只支持 RSA），再用-t rsa -b 4096。
执行后会提示你选择保存路径，默认是~/.ssh/id_ed25519。如果你有多套密钥（比如公司一套、个人一套），可以指定不同文件名，比如~/.ssh/id_ed25519_work。然后会问你要不要设 passphrase（密码短语），设了更安全，但每次用都要输入；可以用ssh-agent来缓存。
3.2 公钥上传与连接验证
生成后，查看公钥内容：
cat ~/.ssh/id_ed25519.pub复制输出的全部内容，粘贴到 GitHub 的 Settings → SSH and GPG keys → New SSH key。标题随便起，能区分就行。
上传后验证连接：
ssh -T git@github.com如果看到Hi 用户名! You've successfully authenticated...就说明配置成功了。这里有个细节：第一次连接时 SSH 会问你是否信任 GitHub 的主机指纹，输入yes即可。如果这一步报错说主机验证失败，可能是~/.ssh/known_hosts里有旧的 GitHub 记录，删掉对应行再试。
克隆命令相应变成：
git clone git@github.com:用户名/仓库名.git注意 URL 格式的区别：HTTPS 是https://github.com/用户名/仓库名.git，SSH 是git@github.com:用户名/仓库名.git。冒号代替了斜杠，前面多了git@。
3.3 多密钥管理与常见报错排查
当你有多套 SSH 密钥时，需要告诉 SSH 客户端哪个主机用哪个密钥。在~/.ssh/config里配置：
Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work IdentitiesOnly yesIdentitiesOnly yes这个选项很关键，它强制 SSH 只使用指定的密钥，避免尝试所有可用密钥导致认证失败。
常见的 SSH 报错有这么几类：
| 报错信息 | 原因 | 解决方式 |
|---|---|---|
Permission denied (publickey) | 公钥没上传或密钥不匹配 | 检查公钥是否在 GitHub 上，用ssh -T验证 |
Bad owner or permissions on ~/.ssh/config | 配置文件权限过宽 | chmod 600 ~/.ssh/config |
Host key verification failed | known_hosts 记录过期 | 删除对应记录或重新接受指纹 |
Could not open a connection to your authentication agent | ssh-agent 没启动 | eval "$(ssh-agent -s)"后ssh-add |
Windows 上还有一个特有的坑：如果你用管理员权限运行过 Git Bash，生成的密钥文件权限可能不对，导致 SSH 拒绝使用。解决办法是确保.ssh目录和密钥文件的权限只对当前用户开放。
SSH 方式一旦配好，后续所有操作都不需要再输入凭证，对于频繁操作多个仓库的开发者来说效率提升非常明显。而且 SSH 走的是 22 端口，通常比 HTTPS 的传输效率略高一些。
4. GitHub CLI：把克隆变成一句话的事
4.1 安装与认证
GitHub CLI（命令是gh）是 GitHub 官方出的命令行工具，它把很多网页端的操作搬到了终端里。安装方式因平台而异：
# macOS brew install gh # Windows（用 winget） winget install --id GitHub.cli # Ubuntu/Debian sudo apt install gh安装后先认证：
gh auth login它会交互式地问你选 GitHub.com 还是企业版、选 HTTPS 还是 SSH、要不要用浏览器登录。跟着提示走就行。认证完成后，gh会帮你把 Git 的凭证也配好，相当于一次性解决了认证问题。
4.2 克隆操作的简化
用gh克隆仓库：
gh repo clone 用户名/仓库名就这么简单，不需要完整的 URL。gh会自动判断用 HTTPS 还是 SSH，并处理认证。对于经常需要克隆各种仓库的人来说，少打很多字。
gh还能做很多克隆之外的事：查看仓库信息、创建 issue、提 PR、查看 Actions 运行状态等等。如果你本来就经常用 GitHub，装一个gh能省不少切换浏览器的时间。
4.3 三种方式的横向对比
| 维度 | HTTPS | SSH | GitHub CLI |
|---|---|---|---|
| 首次配置难度 | 低 | 中 | 低 |
| 日常使用便捷度 | 中（需管理令牌） | 高 | 高 |
| 网络穿透性 | 最好 | 较好 | 取决于底层协议 |
| 多账号支持 | 较麻烦 | 通过 config 配置 | 支持切换 |
| 适合场景 | 偶尔拉公开仓库 | 长期开发私有仓库 | 重度 GitHub 用户 |
| 是否需要额外工具 | 否 | 否 | 需安装 gh |
选择哪种方式，核心看你的使用频率和场景。偶尔用一次，HTTPS 最省事；天天用，SSH 或 gh 更高效。
5. 克隆效率优化：大仓库不再等到天荒地老
5.1 浅克隆与部分克隆
前面提过--depth 1的浅克隆。对于动辄几个 G 历史的大型仓库（比如一些存在多年的前端框架），完整克隆可能要等十几分钟甚至更久。浅克隆只拉最新快照，速度能快一个数量级。
如果后续需要更多历史，可以逐步加深：
git fetch --depth 10 git fetch --depth 100或者直接git fetch --unshallow拉全量。
Git 2.19 之后还引入了部分克隆（partial clone），可以只拉需要的对象：
git clone --filter=blob:none https://github.com/用户名/仓库名.git--filter=blob:none表示先不下载文件内容（blob），只下载提交历史和目录结构。当你实际检出某个文件时，再按需下载。这对于只需要浏览代码结构、不需要全部文件的场景非常有用。
5.2 单分支克隆
默认情况下git clone会把所有分支的引用都拉下来。如果你只关心某一个分支：
git clone --single-branch --branch 分支名 https://github.com/用户名/仓库名.git这样只拉指定分支的历史，数据量更小。对于只做某个功能分支开发的场景很实用。
5.3 网络层面的优化思路
克隆速度慢，很多时候不是 Git 的问题，而是网络到 GitHub 的链路问题。可以从几个方向优化：
- 使用代理：如果你有可用的网络代理，给 Git 配置上：
git config --global http.proxy http://127.0.0.1:端口 git config --global https.proxy http://127.0.0.1:端口用完记得取消：
git config --global --unset http.proxy git config --global --unset https.proxy- 调整 Git 的缓冲设置：大仓库传输时，默认的 postBuffer 可能不够：
git config --global http.postBuffer 524288000这会把缓冲区调到 500MB，减少大包传输失败的概率。
- 选择合适的时间段：这个听起来像废话，但实测下来，网络高峰期的克隆失败率确实更高。如果仓库不急用，可以错峰操作。
提示：以上网络优化手段请确保在符合当地网络使用规范的前提下进行。
6. 克隆之后：那些没人告诉你但迟早会遇到的事
6.1 默认分支的坑
GitHub 从 2020 年开始把新仓库的默认分支从master改成了main。如果你克隆的是一个老仓库，默认分支可能还是master；如果是新仓库，就是main。这本身不是问题，但如果你在脚本里硬编码了分支名，就会出错。
查看当前默认分支：
git branch --show-current或者看远程 HEAD 指向：
git remote show origin6.2 子模块的处理
如果仓库里包含子模块（submodule），git clone默认不会拉取子模块的内容。你会看到子模块目录是空的。需要额外执行：
git submodule update --init --recursive或者在克隆时直接带上：
git clone --recurse-submodules https://github.com/用户名/仓库名.git子模块这个东西，用好了能解耦代码，用不好就是无尽的麻烦。克隆时如果发现某个目录空着，先检查是不是子模块。
6.3 换远程地址的正确姿势
有时候你克隆完才发现，应该用 SSH 而不是 HTTPS，或者仓库迁移了地址。这时候不需要重新克隆，改一下远程地址就行：
git remote set-url origin git@github.com:用户名/仓库名.git改完用git remote -v确认一下。这个操作在切换认证方式时特别常用，比删了重克隆省事得多。
6.4 克隆失败后的清理
如果克隆中途失败，本地会留下一个不完整的目录。直接重新克隆可能会报“目录已存在”。正确做法是先删掉残留：
rm -rf 仓库名然后再重新克隆。不要试图在残留目录里继续操作，容易出各种奇怪的问题。
7. 我个人的选择建议与实战体会
用了这么多年 Git，我的选择其实一直在变。刚入门的时候全程 HTTPS，因为不用配密钥；后来私有仓库多了，切到 SSH，一次配置管很久；再后来装了gh，克隆公开仓库基本就用gh repo clone了，少打很多字。
如果非要给一个建议：新手从 HTTPS 开始，能跑通就行；当你开始频繁操作私有仓库时，花二十分钟配好 SSH，长期收益远超投入；如果你是 GitHub 重度用户，装个 gh，它不只是用来克隆的。
还有一个我踩过的坑值得单独说：不要在多个项目里共用同一个 SSH 密钥。我曾经图省事，所有项目都用同一个密钥，后来其中一个项目的密钥需要轮换，结果所有项目都得重新配置。正确的做法是按用途或按组织生成不同的密钥，通过~/.ssh/config管理。虽然初期麻烦一点，但后期维护成本低得多。
最后再提一个细节：克隆下来的仓库，.git目录可能比你想象的大。如果磁盘空间紧张，可以用git gc做垃圾回收，或者用git count-objects -vH看看对象占用情况。有些仓库历史里包含了大文件，即使删掉了，历史记录里还在，.git目录会一直很大。这种情况需要用git filter-repo之类的工具清理历史，但那属于另一个话题了。
克隆这件事，说简单也简单，一条命令的事；说复杂也复杂，认证、网络、效率、后续维护，每个环节都有讲究。希望这篇内容能帮你少走一些弯路，把时间花在真正写代码上。