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 --timeout3600这样第一次输入后一小时内不用重复输入。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 gitgithub.com如果看到Hi 用户名! Youve successfully authenticated...就说明配置成功了。这里有个细节第一次连接时 SSH 会问你是否信任 GitHub 的主机指纹输入yes即可。如果这一步报错说主机验证失败可能是~/.ssh/known_hosts里有旧的 GitHub 记录删掉对应行再试。克隆命令相应变成git clone gitgithub.com:用户名/仓库名.git注意 URL 格式的区别HTTPS 是https://github.com/用户名/仓库名.gitSSH 是gitgithub.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/configHost key verification failedknown_hosts 记录过期删除对应记录或重新接受指纹Could not open a connection to your authentication agentssh-agent 没启动eval $(ssh-agent -s)后ssh-addWindows 上还有一个特有的坑如果你用管理员权限运行过 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 三种方式的横向对比维度HTTPSSSHGitHub 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 --filterblob:none https://github.com/用户名/仓库名.git--filterblob: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 子模块的处理如果仓库里包含子模块submodulegit clone默认不会拉取子模块的内容。你会看到子模块目录是空的。需要额外执行git submodule update --init --recursive或者在克隆时直接带上git clone --recurse-submodules https://github.com/用户名/仓库名.git子模块这个东西用好了能解耦代码用不好就是无尽的麻烦。克隆时如果发现某个目录空着先检查是不是子模块。6.3 换远程地址的正确姿势有时候你克隆完才发现应该用 SSH 而不是 HTTPS或者仓库迁移了地址。这时候不需要重新克隆改一下远程地址就行git remote set-url origin gitgithub.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之类的工具清理历史但那属于另一个话题了。克隆这件事说简单也简单一条命令的事说复杂也复杂认证、网络、效率、后续维护每个环节都有讲究。希望这篇内容能帮你少走一些弯路把时间花在真正写代码上。
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 --timeout3600这样第一次输入后一小时内不用重复输入。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 gitgithub.com如果看到Hi 用户名! Youve successfully authenticated...就说明配置成功了。这里有个细节第一次连接时 SSH 会问你是否信任 GitHub 的主机指纹输入yes即可。如果这一步报错说主机验证失败可能是~/.ssh/known_hosts里有旧的 GitHub 记录删掉对应行再试。克隆命令相应变成git clone gitgithub.com:用户名/仓库名.git注意 URL 格式的区别HTTPS 是https://github.com/用户名/仓库名.gitSSH 是gitgithub.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/configHost key verification failedknown_hosts 记录过期删除对应记录或重新接受指纹Could not open a connection to your authentication agentssh-agent 没启动eval $(ssh-agent -s)后ssh-addWindows 上还有一个特有的坑如果你用管理员权限运行过 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 三种方式的横向对比维度HTTPSSSHGitHub 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 --filterblob:none https://github.com/用户名/仓库名.git--filterblob: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 子模块的处理如果仓库里包含子模块submodulegit clone默认不会拉取子模块的内容。你会看到子模块目录是空的。需要额外执行git submodule update --init --recursive或者在克隆时直接带上git clone --recurse-submodules https://github.com/用户名/仓库名.git子模块这个东西用好了能解耦代码用不好就是无尽的麻烦。克隆时如果发现某个目录空着先检查是不是子模块。6.3 换远程地址的正确姿势有时候你克隆完才发现应该用 SSH 而不是 HTTPS或者仓库迁移了地址。这时候不需要重新克隆改一下远程地址就行git remote set-url origin gitgithub.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之类的工具清理历史但那属于另一个话题了。克隆这件事说简单也简单一条命令的事说复杂也复杂认证、网络、效率、后续维护每个环节都有讲究。希望这篇内容能帮你少走一些弯路把时间花在真正写代码上。
