GitHub organization and teams

GitHub supports two types of repo owners: user and organization.

A user is a personal account. Their profile is public (github.com/username), and they have their own SSH keys, tokens, and billing.

An organization (org) is the GitHub equivalent of a company. It has its own billing, its own repositories, and its own security settings. Multiple users can be members. One user can be a member of many orgs at the same time (common for open-source contributors working across multiple companies or projects).

Roles within an org

• Owner: full permissions. Can delete the org, change billing, rename.
• Member: access to repos according to permission rules. By default the member role does not grant write access to all org repos, only to those where a grant was explicitly given.
• Outside collaborator: not an org member, but has access to a specific repo. Often contractors or external contributors.
• Billing manager: billing only, no repo access.

Teams

A team is a named group of users. For example, in the org acme there might be teams backend, frontend, and devops. Teams are useful because you can:

• Grant access to a set of repos in one step rather than per user.
• Use them in codeowners: @acme/backend is automatically assigned to PRs on paths tied to that team.
• Mention in comments: @acme/backend notifies every team member.
• Route Slack or email notifications by team.

Teams can be nested: backend/database inherits permissions and members from backend. Convenient for large organizations.

Permissions on a repo

Access to an org repo can be granted three ways:

1. Via team membership: the team has access and you are in the team.
2. Direct grant: the user is added to the repo personally.
3. Outside collaborator: not an org member, but added to the repo directly.

When removing someone, check all three. Removing a user only from the team is often not enough; a direct grant may remain. This is a common mistake during employee offboarding.

Personal settings vs. org settings

A clear division:

• SSH keys, tokens, email, 2FA: at the user level, at github.com/settings.
• Org billing, default permissions, SAML/SSO, audit log: at the org level, at github.com/organizations/acme/settings.
• Settings for a specific repo: at github.com/acme/web/settings.

When you cannot find a setting, think about which scope it belongs to and go to the appropriate level.

SSO and enterprise

Large organizations enable SAML SSO. With SSO:

• Every org member must complete SSO for their GitHub account.
• PATs (personal access tokens) must be SSO-authorized.
• Pushes from machines where SSO has not been completed are rejected.

This is strong security, but it creates UX friction. If you leave the company, the SSO attestation is revoked automatically and your key stops working with the org's private repos.