GitHub个人仓库添加协作者后仍无法push：协作者未获写入权限或未正确配置SSH/HTTPS凭据

Question

协作者在GitHub个人仓库中仍无法`git push`，是最常见的权限与凭据配置类问题。根本原因通常有两个：一是**权限未生效**——个人仓库（非组织）添加协作者后，对方仅获得读取权限（Read），需手动在仓库 Settings → Manage access 中将权限显式设为 **Write**（GitHub不默认授予写入权）；二是**凭据未正确配置**——若使用HTTPS克隆，系统可能缓存了原账户的旧Token或密码，需通过 `git credential reject` 清除并重新认证；若使用SSH，则需确认协作者已将**自己的公钥（而非原仓库所有者的）添加至其GitHub账户**，且本地`git remote` URL为`[e-mail]:username/repo.git`格式。此外，GitHub Personal Access Token（PAT）需勾选 `repo` 权限（非仅 `public_repo`），且2021年后不再支持密码认证。排查时建议结合 `git remote -v`、`ssh -T [e-mail]` 及 `gh auth status` 综合验证。

Answer 1

```html

一、现象层：协作者执行 git push 拒绝访问的典型报错

最常见的错误提示包括：

• remote: Permission to owner/repo.git denied to collaborator-username.
• fatal: unable to access 'https://github.com/owner/repo.git/': The requested URL returned error: 403
• Permission denied (publickey).（SSH 场景）
• remote: Support for password authentication was removed on August 13, 2021.

这些并非网络或 Git 本身故障，而是权限链路中某环断裂的明确信号。

二、结构层：GitHub 协作模型中的「双权限域」解耦机制

GitHub 将权限控制拆分为两个正交维度，必须同时满足：

维度	作用对象	配置位置	默认值
仓库级访问权限	协作者账户对目标仓库的读/写/管理能力	Repo Settings → Manage access → Edit role	Read only（个人仓库！非组织）
凭据级身份认证	本地 Git 客户端向 GitHub 声明“我是谁”	HTTPS（PAT）、SSH（私钥+公钥绑定）、GH CLI（OAuth token）	无默认有效凭据（需显式配置）

二者缺一不可——即使 Manage access 已设为 Write，若凭据未通过 GitHub 认证，仍会拒绝推送。

三、验证层：三步原子化诊断流程（含命令与预期输出）

请协作者在本地终端逐项执行以下验证（顺序不可颠倒）：

1. git remote -v → 确认 URL 格式：
   ✅ HTTPS：应为 https://[e-mail]/owner/repo.git（注意非 https://github.com/owner/repo.git）；
   ✅ SSH：必须为 [e-mail]:owner/repo.git（非 https://... 或 ssh://...）
2. ssh -T [e-mail] → 验证 SSH 身份：
   ✅ 成功输出：Hi collaborator-username! You've successfully authenticated...
   ❌ 失败则说明公钥未添加至 协作者自己的 GitHub 账户 SSH Keys 设置中
3. gh auth status（需安装 GitHub CLI）→ 检查 OAuth/PAT 有效性：
   ✅ 输出含 ✓ Logged in to github.com as collaborator-username 且 ✓ Git operations for github.com
   ❌ 若提示 token does not have required scopes，则 PAT 缺失 repo 权限（非仅 public_repo）

四、修复层：按传输协议分路径精准处置

根据克隆方式选择对应修复策略：

graph LR
  A[协作者无法 git push] --> B{远程 URL 协议？}
  B -->|HTTPS| C[清除凭证缓存 + 重输有效 PAT]
  B -->|SSH| D[确认公钥归属 + 检查 remote URL + 测试连接]
  C --> C1[git credential reject https://github.com]
  C --> C2[git push 触发新认证 → 输入 Personal Access Token]
  C2 --> C3[PAT 必须勾选：repo, workflow, delete_repo]
  D --> D1[ssh-keygen -l -f ~/.ssh/id_rsa.pub → 对比 GitHub Settings 中指纹]
  D --> D2[git remote set-url origin [e-mail]:collaborator-username/repo.git? NO! 应为 owner/repo.git]
  D2 --> D3[正确格式：git remote set-url origin [e-mail]:owner/repo.git]

五、纵深防御：企业级协作建议（面向5年+从业者）

为规避同类问题反复发生，建议建立如下工程化实践：

• ✅ 在团队入职文档中强制要求协作者完成 gh auth login --scopes repo,workflow 并验证 gh auth status
• ✅ 使用 git config --global credential.helper store 替代系统钥匙串（避免 macOS Keychain 自动填充旧凭据）
• ✅ 为每个项目生成专用 PAT（而非复用全局 token），启用细粒度权限与过期时间（如 90 天）
• ✅ 在 CI/CD 流水线中嵌入自动化检查脚本：
  #!/bin/bash
[[ $(git remote get-url origin) =~ ^git@github\.com: ]] || exit 1
ssh -o ConnectTimeout=5 -T [e-mail] &>/dev/null || exit 1
gh auth status &>/dev/null || exit 1

权限不是一次配置，而是持续可验证的信任链。

```