Appearance
Git SSH 与 HTTPS 方式拉取代码详解
一、概述
Git 是目前最流行的分布式版本控制系统，在与远程仓库交互时，主要有两种认证方式：HTTPS 和 SSH。两种方式各有特点，适用于不同的使用场景。
二、HTTPS 方式
2.1 如何使用 HTTPS 拉取代码
1. 克隆仓库
bash
# 克隆公开仓库（无需认证）
git clone https://github.com/username/repository.git
# 克隆私有仓库（需要输入用户名和密码/令牌）
git clone https://github.com/username/private-repo.git2. 配置凭据缓存
为避免每次操作都输入密码，可以配置凭据存储：
bash
# 方式一：缓存凭据（内存中，默认 15 分钟）
git config --global credential.helper cache
# 设置缓存时间（如 1 小时）
git config --global credential.helper 'cache --timeout=3600'
# 方式二：永久存储凭据（明文存储在 ~/.git-credentials）
git config --global credential.helper store
# 方式三：使用系统凭据管理器（推荐，Windows/macOS/Linux）
git config --global credential.helper manager3. 使用个人访问令牌（PAT）
GitHub 等平台已逐步弃用密码认证，需使用 Personal Access Token：
bash
# 创建令牌后，在克隆或推送时使用令牌作为密码
git clone https://github.com/username/repo.git
# Username: your-username
# Password: ghp_xxxxxxxxxxxx（使用个人访问令牌）
# 或直接在 URL 中嵌入令牌
git clone https://username:ghp_xxxx@github.com/username/repo.git4. 已有仓库切换远程地址
bash
# 查看当前远程地址
git remote -v
# 切换到 HTTPS
git remote set-url origin https://github.com/username/repository.git2.2 HTTPS 方式优缺点
优点
| 优点 | 说明 |
|---|---|
| 配置简单 | 无需额外配置，开箱即用 |
| 防火墙友好 | 使用标准 443 端口，几乎不会被防火墙拦截 |
| 代理支持好 | 容易配置 HTTP/HTTPS 代理 |
| 权限控制灵活 | 可以针对不同仓库使用不同的令牌权限 |
| 适合临时使用 | 在陌生机器上临时克隆代码非常方便 |
| 企业环境友好 | 企业内部通常已有 HTTPS 代理基础设施 |
缺点
| 缺点 | 说明 |
|---|---|
| 需要频繁认证 | 每次推送可能需要输入凭据（除非配置缓存） |
| 令牌管理复杂 | 需要创建、更新、管理多个访问令牌 |
| 安全性依赖存储方式 | 明文存储凭据存在安全风险 |
| 大文件传输较慢 | HTTPS 协议开销相对较大 |
| 令牌可能过期 | 需要定期更新令牌 |
三、SSH 方式
3.1 如何使用 SSH 拉取代码
1. 检查现有 SSH 密钥
bash
# 查看是否已有 SSH 密钥
ls -al ~/.ssh
# 常见密钥文件名
# id_rsa / id_rsa.pub (RSA 密钥)
# id_ed25519 / id_ed25519.pub (Ed25519 密钥，推荐)
# id_ecdsa / id_ecdsa.pub (ECDSA 密钥)2. 生成新的 SSH 密钥
bash
# 方式一：生成 Ed25519 密钥（推荐，更安全、更快）
ssh-keygen -t ed25519 -C "your_email@example.com"
# 方式二：生成 RSA 密钥（兼容性更好）
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
# 执行后会提示：
# 1. 选择保存位置（默认 ~/.ssh/id_ed25519）
# 2. 设置密码短语（可选，增加安全性）3. 添加 SSH 密钥到 SSH Agent
bash
# 启动 SSH Agent
eval "$(ssh-agent -s)"
# 添加私钥到 Agent
ssh-add ~/.ssh/id_ed25519
# macOS 可以配置自动加载
# 编辑 ~/.ssh/config，添加：
# Host *
# AddKeysToAgent yes
# UseKeychain yes
# IdentityFile ~/.ssh/id_ed255194. 添加公钥到远程仓库
bash
# 查看公钥内容
cat ~/.ssh/id_ed25519.pub
# 或直接复制到剪贴板
# Windows (Git Bash)
clip < ~/.ssh/id_ed25519.pub
# macOS
pbcopy < ~/.ssh/id_ed25519.pub
# Linux
xclip -sel clip < ~/.ssh/id_ed25519.pub然后到远程仓库平台添加公钥：
GitHub: Settings → SSH and GPG keys → New SSH key → 粘贴公钥 → Add SSH key
GitLab: Preferences → SSH Keys → 粘贴公钥 → Add key
Gitee: 设置 → SSH 公钥 → 添加公钥
5. 测试 SSH 连接
bash
# 测试 GitHub 连接
ssh -T git@github.com
# 测试 GitLab 连接
ssh -T git@gitlab.com
# 测试 Gitee 连接
ssh -T git@gitee.com
# 成功后会看到类似信息：
# Hi username! You've successfully authenticated, but GitHub does not provide shell access.6. 使用 SSH 克隆仓库
bash
# 克隆仓库
git clone git@github.com:username/repository.git
# 已有仓库切换到 SSH
git remote set-url origin git@github.com:username/repository.git7. 配置多个 SSH 密钥（多账号场景）
bash
# 编辑 ~/.ssh/config 文件
# GitHub 个人账号
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personal
# GitHub 工作账号
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
# GitLab
Host gitlab.com
HostName gitlab.com
User git
IdentityFile ~/.ssh/id_ed25519_gitlab
# 使用别名克隆
git clone git@github-work:company/project.git3.2 SSH 方式优缺点
优点
| 优点 | 说明 |
|---|---|
| 一次配置，长期有效 | 配置完成后无需重复认证 |
| 安全性高 | 私钥不通过网络传输，可设置密码短语保护 |
| 操作便捷 | 推送、拉取无需输入密码 |
| 多账号管理方便 | 通过 SSH config 轻松管理多个账号 |
| 性能更好 | SSH 协议开销小，传输效率高 |
| 密钥不过期 | SSH 密钥不会像令牌那样过期 |
| 支持部署密钥 | 可为 CI/CD 配置只读或读写权限的部署密钥 |
缺点
| 缺点 | 说明 |
|---|---|
| 初始配置复杂 | 需要生成密钥、添加到平台、配置 Agent |
| 防火墙可能拦截 | 使用 22 端口，某些网络环境可能被封锁 |
| 密钥需要妥善保管 | 私钥泄露风险大，需要安全存储 |
| 跨设备需要迁移 | 换电脑需要重新配置或迁移密钥 |
| 企业环境限制 | 某些企业可能限制 SSH 出站连接 |
四、两种方式对比
| 对比项 | HTTPS | SSH |
|---|---|---|
| 配置难度 | 简单，开箱即用 | 较复杂，需要生成密钥 |
| 认证方式 | 用户名 + 密码/令牌 | 公私钥对 |
| 端口 | 443（几乎不被封锁） | 22（可能被封锁） |
| 代理支持 | 原生支持 | 需要额外配置 |
| 安全性 | 依赖令牌管理 | 密钥对更安全 |
| 便捷性 | 需要管理凭据 | 一次配置长期有效 |
| CI/CD 集成 | 使用令牌 | 使用部署密钥 |
| 多账号 | 需要多个令牌 | SSH config 灵活管理 |
| 适合场景 | 临时使用、企业环境 | 日常开发、长期项目 |
五、如何选择
推荐使用 HTTPS 的场景
- 临时使用：在陌生机器上临时克隆代码
- 企业环境：公司网络限制 SSH 连接
- 防火墙严格：SSH 端口被封锁的环境
- 需要代理：必须通过代理访问外网
- 初学者：刚接触 Git，不想配置 SSH
推荐使用 SSH 的场景
- 日常开发：频繁推送拉取代码
- 长期项目：不想频繁处理认证问题
- 多账号管理：同时使用多个 Git 平台账号
- CI/CD 自动化：配置部署密钥进行自动化部署
- 安全性要求高：需要更高的安全标准
六、常见问题与解决方案
6.1 HTTPS 相关问题
问题：每次推送都要输入密码
bash
# 解决方案：配置凭据管理器
git config --global credential.helper manager
# 或使用缓存
git config --global credential.helper store问题：GitHub 密码认证失败
bash
# 原因：GitHub 已废弃密码认证
# 解决方案：使用 Personal Access Token (PAT)
# 1. GitHub → Settings → Developer settings → Personal access tokens → Generate new token
# 2. 选择需要的权限
# 3. 使用令牌作为密码问题：配置代理
bash
# HTTP 代理
git config --global http.proxy http://127.0.0.1:7890
# HTTPS 代理
git config --global https.proxy https://127.0.0.1:7890
# 只对 GitHub 使用代理
git config --global http.https://github.com.proxy http://127.0.0.1:7890
# 取消代理
git config --global --unset http.proxy
git config --global --unset https.proxy6.2 SSH 相关问题
问题：SSH 连接超时
bash
# 可能是 22 端口被封锁
# 解决方案：使用 SSH over HTTPS（GitHub 支持）
# 编辑 ~/.ssh/config
Host github.com
Hostname ssh.github.com
Port 443
User git问题：Permission denied (publickey)
bash
# 检查 SSH Agent 是否运行
eval "$(ssh-agent -s)"
# 添加密钥
ssh-add ~/.ssh/id_ed25519
# 检查公钥是否正确添加到平台
ssh -T git@github.com -v问题：多个 GitHub 账号冲突
bash
# 使用 SSH config 配置不同别名
# 编辑 ~/.ssh/config
Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_personal
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_work
# 克隆时使用别名
git clone git@github-personal:username/repo.git七、最佳实践
7.1 安全建议
HTTPS 方式
- 使用凭据管理器而非明文存储
- 为令牌设置最小必要权限
- 定期轮换访问令牌
- 不要在代码中硬编码令牌
SSH 方式
- 使用 Ed25519 算法生成密钥
- 为私钥设置密码短语
- 定期检查已授权的公钥列表
- 私钥文件权限设置为 600
7.2 工作流建议
bash
# 推荐的 Git 配置
git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase false
# Windows 推荐
git config --global core.autocrlf true
# macOS/Linux 推荐
git config --global core.autocrlf input八、总结
| 方式 | 一句话总结 |
|---|---|
| HTTPS | 配置简单、防火墙友好，适合临时使用和企业环境 |
| SSH | 一次配置长期有效、安全性高，适合日常开发 |
对于个人开发者，推荐 SSH 方式，配置一次后长期便捷使用。对于企业环境或有特殊网络限制的场景，HTTPS 方式 更加灵活可靠。两种方式也可以同时使用，根据不同仓库的需求灵活切换。