What are GitHub's repository access roles, and what can each one do?

## Why roles exist A Git repository has no notion of who may push — that is entirely the hosting platform's job. GitHub answers it with a small, fixed ladder of **repository roles**. Instead of a matrix of individual capabilities, you assign one role and inherit a documented bundle of permissions. Keeping the ladder short is deliberate: it makes access reviewable at a glance, which is the whole point of an authorization model. ## The five roles **Read** is the baseline. A Read user can view the code, clone and fetch it, fork it where forking is allowed, open issues and pull requests from a branch they control, comment, and watch or star the repository. Read cannot push to any branch. **Triage** is Read plus issue-and-pull-request stewardship without code access. A triager can apply and remove labels and milestones, assign people, close and reopen issues and pull requests, mark duplicates, and request reviews. This is the role for a community maintainer or a product manager who runs the backlog but never lands code. **Write** is the everyday contributor role. On top of Triage it can push to branches that are not protected, create and delete branches, merge pull requests they are allowed to merge, and create and edit releases. Most engineers on a team hold Write and nothing more. **Maintain** is Write plus repository management that is neither sensitive nor destructive: editing the description and topics, toggling features such as wikis, issues and projects, and general project stewardship. Crucially it stops short of the dangerous levers — a Maintain user cannot change visibility, transfer or delete the repository, or manage who else has access. **Admin** is total control of the repository: managing collaborators and team access, configuring branch protection and rulesets, managing repository-level secrets and integrations, changing visibility, transferring and deleting. Admin is the role you should grant to the fewest people who can still run the project. ## Where a role actually comes from The role attached to a person is rarely a single grant. It can arrive from the organization's **base permission** (an org-wide default applied to every org member on every repository), from a **team** the person belongs to (including a team they inherit access through as a member of a nested child team), or from a **direct collaborator grant** on that one repository. **Organization owners** hold administrative access to every repository in the org whether or not any of those grants exist, and **outside collaborators** — people with repository access who are not org members — have only direct per-repository grants. When several sources apply, the effective access is the **highest** one. Adding someone to a team with Read does not demote the Write they already hold elsewhere; you have to remove the source that grants the higher level. ## Custom repository roles The five-rung ladder is coarse: sometimes you want "Write, but also allowed to manage one specific setting", or "Maintain, minus release creation". On Enterprise plans GitHub supports **custom repository roles**, defined at the organization level by inheriting one of the base roles and then adding or removing individual fine-grained permissions. The custom role then appears alongside the built-ins when granting access. Everywhere else the fixed ladder is what you get, and the honest answer to "can I grant just this one capability" is often no. ## Reading roles back Roles are visible in the repository's access settings, and through the API: the collaborators endpoint reports a `role_name` per user plus a boolean `permissions` object, and a per-user permission endpoint reports the effective level. Reading roles back programmatically is how access reviews are done at scale, because the UI shows a page at a time. ## Common mistakes The two mistakes interviewers listen for are granting Admin because someone needed one setting — which hands them deletion and visibility as well — and granting access to individuals instead of teams, which makes offboarding a manual hunt across hundreds of repositories. The second failure is the more expensive one, because nothing surfaces it until an audit.