How do you manage repository access and permissions on GitHub?

Think of GitHub access control like a corporate office building. The organization is the building itself with its own address and security policies. Teams are departments within the building, each with access to their own floors and rooms. Individual collaborators are visitors given temporary badges to specific rooms. The building owner (org owner) controls everything, department heads (team maintainers) manage their own teams, and each room (repository) has its own lock settings (branch protection) that even department members must follow.

GitHub Organizations are the top-level entity for managing repositories and people in a professional setting. An organization has owners who control billing, security settings, and member management. Members of the organization can be organized into teams with hierarchical structures (engineering/frontend, engineering/backend). Each team can be granted one of five permission levels on specific repositories: Read (view and clone), Triage (manage issues without code access), Write (push to non-protected branches), Maintain (manage repository settings without destructive access), and Admin (full control including deleting the repository). These permissions are additive. If a user belongs to two teams with different permission levels on the same repository, they get the higher permission.

Beyond team permissions, repositories have settings that add additional controls. Branch protection rules are the most important: they can require pull request reviews before merging, require specific status checks to pass, restrict who can push to protected branches, require signed commits, enforce linear history (no merge commits), and require conversation resolution before merging. These rules apply regardless of the user's permission level, so even an admin must go through a pull request if the rules are configured that way (unless they have the 'bypass branch protections' permission).

In production, a typical organization structure has an engineering team with sub-teams for each service domain. The platform-team has admin access to infrastructure repositories like terraform-modules and k8s-manifests. The payments-team has write access to payments-api and read access to shared-libraries. Contractors or external consultants are added as outside collaborators with scoped access to specific repositories. Two-factor authentication (2FA) is enforced at the organization level, SAML SSO integrates with the company's identity provider (like Okta or Azure AD), and audit logs track every permission change, repository creation, and member action.

A common gotcha is that organization owners have implicit admin access to all repositories, which cannot be restricted. If you need to limit access for compliance reasons (like SOX requirements for financial code), use GitHub's Enterprise features with custom repository roles. Another mistake is granting admin access when write access would suffice. Admin permissions allow destructive actions like deleting the repository, changing visibility, and modifying branch protection rules. Follow the principle of least privilege: most developers need write access, not admin.