Permissions and roles in GitHub
Design and implement permissions and roles in GitHub
Repository roles
| Role | Can |
|---|---|
| Read | Clone, open issues and pull requests |
| Triage | Manage issues and PRs without write access |
| Write | Push to non-protected branches |
| Maintain | Manage the repository without destructive or sensitive actions |
| Admin | Everything, including deletion and settings |
Triage and Maintain exist to avoid the common over-grant: someone who needs to manage issues does not need push access, and someone who administers repository settings day to day does not need the ability to delete it.
Teams
Grant access to teams, not individuals. Team membership then becomes the single place joining and leaving are handled, and nested teams inherit parent permissions — which models an organisation chart without duplicating grants.
Outside collaborators
An outside collaborator has access to specific repositories without being an organisation member. That is the correct mechanism for a contractor or partner: access is explicit, scoped per repository, and auditable, and they do not inherit anything that applies to members generally.
Branch protection
Roles say who may push; branch protection rules say what may be pushed to a protected branch — required reviews, required status checks, restrictions on who may merge. Both are needed: a Write role plus an unprotected main is an unreviewed production path.
Primary sources