类型：代码托管平台
简介：只支持Git作为唯一的版本库格式进行托管，故名GitHub。
GitHub 仓库一旦多人协作，就会遇到权限分配问题。谁能改设置，谁能合并代码，谁能管理 Secrets，谁只能提交 Pull Request？如果所有人都给最高权限，操作方便但风险很高；如果权限过低，又会影响正常协作。理解 Owner、Maintainer、Collaborator 等角色差异，是管理开源项目和团队仓库的基础。
一、先区分个人仓库和组织仓库
个人账号下的仓库，可以邀请 Collaborator 参与协作。组织仓库则通常通过团队和角色管理权限，更适合多人项目。个人仓库简单，但权限边界较粗；组织仓库设置更多，也更适合长期维护。
如果项目从个人试验变成团队项目，建议迁移到组织下管理。这样可以用团队分组、角色权限、审计记录和更细的访问控制，避免所有权限都绑在某个个人账号上。
二、Owner权限要非常克制
Owner 通常拥有最高管理能力，可以改组织设置、管理成员、删除仓库或调整关键安全配置。这个角色不适合随意分配。只有真正负责组织管理和安全的人，才应该拥有 Owner 权限。
小团队常见错误是为了省事把多人设为 Owner。短期方便，长期风险很高。成员账号被盗、误删仓库、改错安全设置，影响都会扩大。Owner 数量应少而稳定，并启用双因素认证。
三、Maintainer适合项目负责人
在组织和团队场景中，Maintainer 更适合负责项目日常维护的人。维护者需要管理 Issue、PR、分支、发布和部分设置，但不一定需要组织最高权限。把日常项目管理交给 Maintainer，比直接给 Owner 更安全。
如果某个成员只负责一个仓库，就不要给组织级 Owner。按仓库或团队授权，更符合最小权限原则。
四、Collaborator适合外部协作者
个人仓库邀请外部成员时，常用 Collaborator。根据权限级别不同，协作者可以读取、提交、管理 Issue 或合并代码。对短期合作、外包开发、文档协作，Collaborator 比共享账号安全得多。
不要把账号密码发给别人共同使用。共享账号既不安全，也无法追踪是谁做了操作。GitHub 的邀请和权限系统就是为了避免这种情况。
五、读、写、维护、管理权限怎么选
只需要查看私有仓库，就给 Read；需要提交分支或打开 PR，可以给 Write；需要管理 Issue、PR、分支和发布，可以给 Maintain；需要改仓库设置、管理权限和删除关键内容，才考虑 Admin。权限越高，越要谨慎。
一个实用判断是：这个人完成当前工作，最低需要什么权限？如果只需要改文档，不必给 Admin；如果只需要提交 PR，不必允许直接改默认分支；如果只负责部署，不必拥有组织成员管理能力。
六、分支保护能弥补部分写权限风险
即使成员有写权限，也可以通过分支保护限制直接推送 main。这样协作者可以创建分支、提交 PR，但不能绕过审查直接合并。权限管理和分支保护应该一起使用。
如果仓库里有生产部署 Secrets，仅靠写权限控制不够。需要结合 Environments、审批和 Secrets 范围，避免普通改动意外触发生产部署。
七、人员变动后的权限清理
成员离开团队、合作结束、账号长期不用，都应及时移除权限。很多安全事件不是来自新授权，而是旧权限忘记清理。建议定期检查组织成员、团队列表、外部 Collaborator 和部署密钥。
如果成员账号曾接触生产 Token，还应考虑轮换相关密钥。移除 GitHub 权限不等于撤销第三方服务凭证，两个动作都要做。
八、审计和记录很重要
组织仓库可以查看部分审计信息，了解成员加入、权限变化、关键操作记录。对重要项目，权限变更最好有简单记录，至少知道为什么给、给到什么时候、谁负责回收。
权限管理的目标不是限制协作，而是让协作边界清楚。能用低权限完成的事，就不要给高权限；能用团队授权，就不要依赖个人临时授权；能用 PR 流程控制，就不要让所有人直推主分支。这样项目越做越大时，也不会因为早期随意授权留下隐患。
九、权限分配前先列任务清单
给权限前，不妨先把对方需要完成的任务列出来：查看代码、提交修改、管理 Issue、合并 PR、配置 Actions、管理成员、发布版本。不同任务对应不同权限层级。只要任务不需要管理仓库设置，就不应直接给 Admin 或 Owner。
这种做法能减少“先给高权限，之后再说”的惯性。临时协作可以给较低权限，并约定结束时间；长期维护者再逐步提升权限。权限应随责任变化，而不是随关系亲近程度变化。
十、外部协作者更适合走PR
外部成员如果只是贡献文档、修复小问题或参与短期功能开发，通常让其 Fork 后提交 PR 更安全。只有当协作频繁、需要直接维护分支时，再考虑写权限。这样既能接受贡献，又不会让仓库暴露过多操作入口。
对私有仓库，外部 Collaborator 也要定期检查。合作结束后及时移除，相关部署密钥和第三方服务权限也要同步清理。GitHub 权限只是整个访问链路的一部分。
十一、组织团队能减少重复授权
当仓库数量变多时，逐个给个人授权很容易混乱。组织可以按团队授权，例如 frontend、docs、ops，每个团队对应一组仓库权限。成员加入或离开团队时，权限自动变化，比逐仓库调整更可靠。
团队授权也方便审计。维护者可以快速看到某个团队拥有哪些仓库权限，而不是在每个仓库里查个人名单。对长期运营的网站项目，这种方式比个人临时授权更适合规模化管理。
十二、高权限账号必须加强账号安全
Owner、Admin、Maintainer 账号应启用双因素认证，并避免使用弱密码或共享设备长期登录。权限管理不只发生在仓库设置里，也发生在账号安全上。一个高权限账号被盗，比普通成员误操作更危险。
如果组织支持强制 2FA，应尽量开启。对生产相关仓库，还可以结合分支保护、环境审批和审计记录，把单个账号失误造成的影响降到更低。权限越高，越需要额外保护。
