git clone 是标准命令，无替代实现；支持 HTTPS（需 PAT）、SSH（需密钥配置）等协议；常用参数包括 -b 指定分支、--single-branch 限分支、--depth 浅克隆、--recursive 含子模块。
git clone 命令本身没有“多种实现方式”，只有不同协议、不同参数组合和不同认证机制下的使用变体。直接用 git clone 就是标准做法，不存在“替代命令”或“底层重写”。
HTTPS 克隆：最通用，但要注意凭据失效
适合没配 SSH 密钥、临时协作或 CI 环境。URL 形如 https://github.com/user/repo.git 或 https://dev.azure.com/org/project/_git/repo。
常见问题：
- 输入密码失败后反复报
403 Forbidden：GitHub 已停用密码登录，必须改用personal access token；Azure DevOps 也要求 PAT 或 OAuth token - 双因素认证（2FA）启用后，直接输账号密码必然失败
- Windows 上偶尔因缓存旧凭据导致拒绝访问，可运行
git credential reject清理
安全建议：不要把 token 写进 URL（如 https://user:token@github.com/...），容易泄露到 shell 历史或日志。优先配置 git config --global credential.helper store 或使用系统钥匙串。
SSH 克隆：免密、稳定，但需提前配置密钥
URL 形如 git@github.com:user/repo.git 或 git@gitlab.com:group/project.git。这是团队开发首选。
关键点：
- 必须在本地生成 SSH key（
ssh-keygen -t ed25519 -C "your_email@example.com"），并把公钥（~/.ssh/id_ed25519.pub）添加到对应平台的 SSH Keys 设置页 - 首次连接会提示确认 host key，输
yes即可；之后自动认证，无需每次输密码 - 如果
git clone卡住不动，先执行ssh -T git@github.com测试连通性
注意：GitLab / Azure DevOps 的 SSH URL 格式可能略有差异（比如 Azure DevOps 要求 ssh:// 前缀），别直接套用 GitHub 的写法。
克隆时指定分支或浅层历史：不是“另类方法”，而是明确意图
默认 git clone 拉取全部分支和完整历史，对大仓库来说既慢又占空间。实际开发中常加参数控制：
- 只检出某一分支（如
main或develop）：git clone -b main --single-branch https://... - 跳过历史，只拉最近一次提交（CI 构建常用）：
git clone --depth 1 https://... - 带子模块一起拉：
git clone --recursive https://...，否则子模块目录为空
⚠️ 注意：--depth 1 后本地仓库无法 git pull 切换其他分支，也不能 git log 查历史 —— 它就是个“快照”，不是完整仓库。
克隆后远程名 origin 不是固定的，但别轻易改
git clone 默认把远端地址记为 origin，这是约定俗成，不是硬编码。你可以用 git remote rename origin upstream 改，但得同步改所有脚本和 CI 配置里写的 origin。
更常见的是添加第二个远端（比如同步上游开源项目）：git remote add upstream https://github.com/upstream/repo.git。这时候 origin 仍指向你自己的 fork，不会冲突。
容易忽略的一点：克隆完立刻 git remote -v 看一眼 URL 是否符合预期 —— 有时候复制 URL 多了个空格、少了 .git 后缀，或者 HTTPS 和 SSH 混用了，错误要趁早发现。
