iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
“Highest wins” is only part of how GitHub organization repository permissions work. A repository-specific grant can override a lower organization base permission, but grants through different access paths can also combine. To find what someone can actually do, check both the permission level and where each grant comes from.
How organization repository permissions work
A permission is an action someone is allowed to perform; a role is a bundle of permissions. GitHub’s organization repository roles are ordered from least to most access, but the roles are not simply interchangeable points on a scale: each includes different capabilities. The descriptions below follow GitHub’s repository role documentation.
| Role | Typical use | What it allows, in broad terms |
|---|---|---|
| Read | People who need to view and discuss a project | Read repository contents and participate in discussions. |
| Triage | Issue, discussion, or pull-request coordinators who do not need code write access | Manage issues, discussions, and pull requests without write access to the repository. |
| Write | Active code contributors | Contribute to the repository with write access. |
| Maintain | Project managers who need repository-management capabilities | Manage the repository without the sensitive or destructive powers reserved for administrators. |
| Admin | People responsible for full repository administration | Full access, including security management and repository deletion. |
Choose based on the actions a person needs, not their job title. A project manager who only coordinates issues may need Triage; one who needs broader repository management may need Maintain. Reserve Admin for responsibilities that require its sensitive or destructive controls.
What “highest wins” means for base permissions
An organization owner can set a base permission that gives organization members a default level of access across the organization’s repositories. This setting does not apply to outside collaborators. A higher repository-specific grant can override a lower organization base permission, which is the specific situation behind the “highest wins” shorthand. See GitHub’s documentation on organization base permissions.
#1 Best Overall
That rule does not mean every grant is collapsed into one maximum role. GitHub documents grants through different avenues as additive. Its custom-role guidance gives the example of members receiving Write base access plus extra permissions from a custom role based on Read. GitHub states: “Roles and permissions are additive.” When access paths conflict, GitHub can display “Mixed roles.” Read the grants as a set of sources and permissions, not just a single label. Details appear in GitHub’s custom repository role documentation.
How to check a person’s access to a repository
- Open the repository, select Settings, then under Access select Collaborators & teams. People with repository admin access can review and adjust access there. GitHub documents this screen in its organization repository permission-level guide.
- Review both Direct access and Organization access. This helps distinguish access granted directly from access received through an organization role or team.
- If the person’s entry shows Mixed roles, inspect the warning or open the label to identify the contributing grants. Then change the source that needs correction—such as the organization base permission, team access, or custom role—rather than assuming one role label tells the whole story.
- If access is inherited through a team hierarchy, adjust it at the parent team. GitHub says changing or removing a parent team’s repository access propagates to child teams.
What to consider before changing the organization default
Changing an organization’s base permission affects existing members as well as new ones. It does not automatically update permissions for private forks. For internal repositories, the minimum visibility level is Read even if the base permission is set to none. Account for those effects when planning a change; GitHub describes them in its base permissions guidance.
Rank #2
Custom repository roles: availability and limits
Custom repository roles let an organization start with an inherited role and add permissions that are not already included in it. GitHub documents this feature for organizations using GitHub Enterprise Cloud. Its current documentation says organizations can create up to 20 custom repository roles; GitHub Enterprise Server versions earlier than 3.19 support up to five. These limits depend on edition and version, so verify the applicable documentation for your organization before planning around them. See GitHub’s custom repository role guide.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
