7.2. Access Permissions and Roles
Not everyone who can see a repository can change it — GitHub layers permission roles to control exactly that, at both the repository and organization level.
💡 First Principle: Access on GitHub is governed by roles that grant an increasing scope of permission — the five default repository roles are Read, Triage, Write, Maintain, and Admin — with a parallel set of roles at the organization level. Triage sits between Read and Write (manage issues and pull requests without pushing code), and Maintain sits between Write and Admin (manage most repository settings without destructive or security-sensitive access). A role determines what an account can do (view, push, merge, change settings), which is a separate question from what a repository's visibility setting controls (who can see it at all — covered in 7.4). An outside collaborator is someone given access to a specific repository without being a member of the owning organization at all.
⚠️ Exam Trap: Permission role and repository visibility are two separate controls that answer two separate questions — role controls what an authorized person can do, visibility controls who can see the repository in the first place. A private repository still needs roles assigned to determine what its members can do inside it.
Reflection Question: An organization wants a contractor to have write access to exactly one repository, without making them a member of the organization or giving them access to any other repository. What kind of access fits that need?
