GitHub上给成员设只读权限即授予Read权限：进入仓库Settings→Collaborators and teams→Add people→输入用户名/邮箱→下拉选Read→发送邀请；Read成员可clone、pull、查看历史和Issue，但禁止push、建分支、改Wiki或访问Settings。
GitHub 上怎么给成员设只读权限
GitHub 默认不提供“只读”这个独立角色名，但 Read 权限就是实际的只读权限——它允许克隆、拉取、查看提交历史和 Issue，但禁止 git push、创建分支、修改 Wiki 或管理设置。
操作路径很直接：进入仓库 → Settings → Collaborators and teams → Add people → 输入用户名/邮箱 → 在下拉菜单中选 Read（不是默认的 Write）→ 发送邀请。
- 被邀请者接受后，
git clone和git pull正常，但执行git push会报错：remote: Permission to owner/repo.git denied to username - 如果误选了
Write，可在同一页面点击用户右侧的⋯→Edit role改回Read -
Read成员无法看到私有仓库的 Settings 标签页，也看不到 “Code” 页里的 “Settings” 按钮
GitLab 中如何分配 Reporter（只读）角色
GitLab 的 Reporter 角色等价于只读权限，比 GitHub 的 Read 略宽一点：允许编辑 Wiki、创建 Issue、评论 MR，但依然不能推送代码或修改分支保护规则。
添加方式：项目页左侧 → Members → Invite members → 填用户名/邮箱 → 角色下拉选 Reporter → 点击 Invite。
- 注意：GitLab 不支持对单个用户降级为
Guest后仍保留克隆权限——Guest无法git clone私有仓库，公有仓库才可读 - 若成员已存在且权限过高，直接在成员列表里点其角色旁的铅笔图标修改即可，无需先移除再重邀
- 权限变更立即生效，无需重启服务或刷新 token
自建 Git 服务器（裸仓库）实现只读访问
没有 Web UI 时，只读本质是文件系统权限控制 + SSH 账户隔离。核心思路是：让只读用户能 git clone（即读取 objects/ 和 refs/），但无法写入 refs/heads/ 或 objects/。
典型做法是用不同系统用户 + 组权限隔离：
- 创建只读用户：
sudo adduser readonly-user，禁用密码登录（仅用 SSH 公钥） - 将该用户加入仓库所在组，例如
sudo usermod -aG git-repo-group readonly-user - 确保裸仓库目录权限为
770，且组拥有写权限仅限于可写成员：chmod -R 770 /path/to/repo.git - 关键一步：运行
git config --file /path/to/repo.git/config core.sharedRepository group，否则新对象可能因 umask 导致组不可读
此时 readonly-user 可以 git clone readonly-user@server:/path/to/repo.git，但 git push 会因目录无组写权限而失败。
容易忽略的只读陷阱
只读不是绝对安全，几个常见盲区：
- GitHub/GitLab 的
Read或Reporter成员仍可 Fork 私有仓库（只要账户有 Fork 权限），Fork 后的新仓库归其个人所有，原始仓库管理员无法控制 - 如果开启了
Allow merge requests from contributors（GitLab）或Allow edits from maintainers（GitHub），只读成员发起的 PR 可能被合入——这等于绕过只读限制 - 本地
.git/config若误配了pushDefault或远程 URL 写成了https://且凭据缓存了写权限，git push可能静默失败或弹窗要密码，而非明确报权限错误 - 使用
git archive或直接scp拉取refs/文件也能获取历史快照，这不是权限问题，而是只读本身不防导出
真正需要防泄露的场景，得配合分支保护、敏感分支设为仅特定角色可推、禁用 Fork 等组合策略，单靠“只读”角色远远不够。
