The organization is your company's account. Namespaces are the workspaces inside it, each with its own members, administrators, and repositories. Joining the organization grants nothing until someone is added to a namespace.
If you know GitHub: an organization here works like an enterprise account, and a namespace like one of its organizations.
Organization
People join here. No repository access yet.
payments
platform
A member of payments has no access to platform.
Keeping the two apart means adding someone to the company account is safe by default, and each team decides who works in its own space.
Where people join, and where the things every team shares are managed. Joining the organization gives no repository access on its own.
Where the work happens. Each namespace has its own members and repositories, and being a member of one gives no access to another.
A person works in a namespace only while they are a member of it. The members list shows each reason someone belongs, and organization administrators keep full access everywhere.
An organization or namespace administrator adds an existing organization member to the namespace.
Invite someone new straight into the namespaces they need, so they land in the right place on day one.
Attach an organization Team to a namespace and everyone on the Team becomes a member of it.
Let a namespace add people who join the organization later, or turn it off to keep the namespace to selected people.
The base permission sets the floor, Teams and roles add to it, and every grant can be explained.
Choose the role every member of a namespace receives on all of its repositories, or none at all.
Read about base permissions →Grant the built-in Reader, Publisher, Maintainer, and Admin roles, or custom roles, on a whole namespace or one repository.
Read about roles →Grant access to a Team once instead of member by member, across namespaces or inside a single one.
Read about Teams →Hand one namespace to its own administrators. They manage its members, Teams, grants, and repositories, not billing or the organization.
Read about namespace administration →See every repository a member can use and each reason why, so access reviews do not depend on guesswork.
Read about effective access →Give CI and release pipelines organization-owned credentials, restricted to one namespace when that is all they need.
Read the token guide →Start with one namespace and a few members, then add namespaces, Teams, and administrators as the organization grows.
Create the organization. Each person keeps their own account for sign-in.
Add a namespace for each team or product that owns repositories.
Invite people into the organization and the namespaces they need.
Set each namespace's base permission, then grant roles to members or Teams.
Appoint namespace administrators so each team can run its own space.
Issue automation tokens for CI and release pipelines.
Create an account, create an organization, and add the namespaces, people, and pipelines that publish and install.
