GitHub Explained Simply — Accounts, Repos, Orgs & Enterprise

A plain-language guide to how GitHub is structured. All facts verified against GitHub's official documentation (docs.github.com).

---

1. The Big Picture

Think of GitHub like an office building:

GitHub thing	Office analogy	What it really is
Enterprise	The whole building + landlord	Central billing, rules, security for the entire company
Organization	One company floor	Shared account that owns repos and people
Team	A department on that floor	Group of people used to hand out access
Repository	A single project room	The actual code + issues + CI/CD
Personal account	Your personal ID badge	One human being on GitHub

The tree

Enterprise account            (optional — only big companies)
   |
   +-- Organization A
   |      +-- Teams (can be nested)
   |      +-- Repositories
   |             +-- Branches, Issues, Pull Requests, Actions
   |
   +-- Organization B
          +-- ...

Personal account              (every human has one; can own repos too)

The one rule people get wrong

An Enterprise account cannot own repositories directly. Repositories are always owned by an Organization or a Personal account. The Enterprise only owns Organizations.

---

2. The Three Account Types

Only these three can own things or be billed.

Account type	Can you log into it?	Owns repos?	Made for
Personal account	Yes (this is you)	Yes	One individual person
Organization	No — it has no password	Yes	A team, company, or open-source project
Enterprise account	No	No — it owns organizations	Big companies with many organizations

Simple way to remember:

• Personal = me
• Organization = us
• Enterprise = the whole company

---

3. Repository (the actual project)

A repository — or "repo" — is a folder of code with full history, plus all the collaboration tools around it.

What lives inside a repo

Part	What it does
Git data	Your files, branches, tags, commit history
Issues	To-do list / bug tracker
Pull requests (PRs)	"Please review and merge my changes"
Actions	Automation & CI/CD (files in .github/workflows/)
Packages	Store built artifacts (containers, npm, NuGet, etc.)
Releases	Downloadable versions of your software
Wiki / Discussions	Documentation and Q&A (optional)
Settings	Branch rules, secrets, environments, webhooks

Repository visibility

Visibility	Who can see it	Available on
Public	Everyone on the internet	All plans
Private	Only people you invite	All plans
Internal	Everyone in your enterprise (read access by default)	Enterprise Cloud / Enterprise Server only

Internal repos are for "innersource" — code that all your employees can find and reuse, but the public cannot see.

---

4. Who Can Do What in a Repository

GitHub has 5 built-in repository roles, from least to most access:

Role	What they can do	Good for
Read	View code, open issues and PRs	Reviewers, non-coders, stakeholders
Triage	Read + manage issues/PRs (label, assign, close) — cannot push code	Community helpers, support staff
Write	Push code, merge PRs	Developers on the project
Maintain	Write + some repo settings — no destructive or security settings	Project managers, leads
Admin	Everything, including delete & transfer the repo	Repo owners

Custom repository roles (mix your own permissions) are available only on GitHub Enterprise Cloud.

---

5. Organizations (where real teamwork happens)

An organization is a shared account. Nobody logs in as the organization — people log in as themselves and are members of it.

Organization-level roles

Role	What it means
Owner	Full control — all repos, settings, billing. Keep this list short, but never fewer than 2 people.
Member	The normal role. By default can create repos and projects.
Moderator	Member + can block users, set interaction limits, hide comments
Billing manager	Billing only — no access to any code
Security manager	Can view security alerts and manage security settings across all repos
Outside collaborator	Not a member. Given access to specific repos only. Cannot see the member list.

Custom organization roles also exist — but only on GitHub Enterprise Cloud.

Base permissions (very important setting)

"Base permission" is one switch that gives every member a default access level on every repo in the organization.

Option	Effect
None	Members get nothing by default — you grant access explicitly
Read	Everyone can read every repo
Write	Everyone can push to every repo
Admin	Everyone is an admin (almost never a good idea)

Best practice: set it to None, then grant access through teams. This is the least-privilege approach.

---

6. Teams (how you hand out access at scale)

A team is just a named group of people. You give the team access to a repo, then add or remove people from the team.

Feature	How it works
Nesting	Teams can have parent and child teams. A parent can have many children; each child has exactly one parent.
Inheritance	Child teams automatically inherit the parent's repo access. You cannot give a child less than its parent.
@mentions	Type @org/team-name to notify the whole team
CODEOWNERS	Auto-request reviews from the right team
IdP sync	Team membership can be synced from Entra ID / Okta groups, so access follows your identity provider
Enterprise teams	Teams can also be created at the enterprise level and then added to organizations

Inheritance example:

Employees
   └── Engineering            ← give this team Write on repo X
         └── App Engineering  ← also gets Write (inherited)
               └── Identity   ← also gets Write (inherited)

Note: Team Discussions have been retired. Use organization-level GitHub Discussions instead.

---

7. Enterprise Accounts (for large companies)

The enterprise account is the central admin console sitting above your organizations.

Three flavours

Flavour	Where it runs	How users sign in
Enterprise Cloud (standard)	github.com	People use their own personal GitHub accounts; you add SAML SSO + SCIM on top
Enterprise Cloud with EMU	github.com	GitHub creates the accounts from your identity provider; users don't own them
Enterprise Server	Your own servers / VM	Local accounts, LDAP, or SAML

What an enterprise controls

Area	Examples
Repositories	Which visibilities are allowed, who can create/delete/fork
Actions	Which actions may run, self-hosted runner groups, retention
Security	Require 2FA, secret scanning, push protection, Dependabot
Access	SAML/OIDC SSO, SCIM provisioning, IP allow lists
Audit	Audit log streaming and API access
Rulesets	Branch/tag rules that apply across all organizations

Rule of thumb: policies flow downward and get stricter. An organization can be more restrictive than the enterprise, never less.

---

8. Enterprise Managed Users (EMU) — read before you choose it

With EMU, GitHub creates and deletes accounts based entirely on your identity provider (via SCIM).

How it looks

• Username is auto-generated and gets your enterprise shortcode added as a suffix.
• Shortcode is 3–8 alphanumeric characters, joined with an underscore — e.g. jdoe_contoso.

What EMU users cannot do

Restriction	Detail
Public contributions	Can only contribute to private and internal repos inside the enterprise
Wider GitHub	Read-only — cannot star, watch, fork, comment, or open issues outside the enterprise
Public repos	Their own personal repos can only be private
Forking outside	Cannot fork repos from outside the enterprise
Following	Cannot follow users outside the enterprise
Authentication	No password and no GitHub 2FA — the IdP handles it entirely
Copilot	Cannot use Copilot Free or Copilot Pro — must be given a Copilot Business/Enterprise seat
Codespaces	Only enterprise-owned codespaces; not for personal repos

EMU is a one-way door. You cannot convert an existing organization full of personal accounts into an EMU enterprise — it needs a new enterprise and a migration project.

---

9. Plans at a Glance

Plan	Applies to	Highlights
Free	Personal & organizations	Unlimited public and private repos; limited feature set on private repos
Pro	Personal accounts	Advanced features on private repos, more Actions minutes
Team	Organizations	Protected branches on private repos, CODEOWNERS, draft PRs
Enterprise Cloud	Enterprise	SSO/SAML, audit log API, internal repos, custom roles, EMU option
Enterprise Server	Self-hosted	Included with Enterprise Cloud licences

Security add-ons: advanced security features (code scanning, secret scanning with push protection, dependency review) are sold separately from the core plan. GitHub has repackaged these more than once, so always check the current GitHub pricing page rather than relying on any guide.

---

10. Coming from Azure DevOps?

GitHub	Closest Azure DevOps / Microsoft idea	Watch out for
Enterprise account	Tenant / management group	Not an identity boundary unless you use EMU
Organization	Azure DevOps organization	See the missing layer note below
Team	Security group / ADO team	Can be synced from Entra ID
Repository	ADO Git repo	GitHub repo also carries issues + CI/CD
Rulesets / branch protection	ADO branch policies	Rulesets can apply at org and enterprise level
Actions	Azure Pipelines	YAML lives in .github/workflows/
Environments + secrets	Environments + variable groups	Supports OIDC federation to Azure — no stored secrets

The missing "Project" layer

Azure DevOps has: Organization → Project → Repo GitHub has: Organization → Repo (no Project layer)

People usually work around this with:

• Naming conventions, e.g. payments-api, payments-web
• Teams that map to what would have been a project
• Organization-level Projects boards that span several repos
• Repository custom properties for governance and grouping

---

11. Which Structure Should You Use?

Your situation	Recommended setup
Just me, side projects	Personal account + private repos
Small team or startup	One organization on the Team plan, access via teams
Company with several business units	Enterprise Cloud + one organization per business unit or product
Strict identity control / regulated	Enterprise Cloud with EMU + IdP provisioning via SCIM
Air-gapped or data residency rules	Enterprise Server (self-hosted)

Five habits that keep things clean

1. Keep the number of organizations low. Each one is a separate permission island and more admin work.
2. Set base permissions to None. Grant access explicitly through teams.
3. Drive team membership from your identity provider. Joiners and leavers then handle themselves.
4. Use rulesets at organization or enterprise level instead of repeating branch protection on every repo.
5. Have at least two organization owners. One person leaving should never lock you out.

---

12. Quick Glossary

Term	Meaning in one line
Repo	A project folder with full version history
Branch	A parallel line of work inside a repo
Fork	Your own copy of someone else's repo
Clone	Downloading a repo to your computer
Pull request	A request to merge one branch into another
Issue	A task, bug, or discussion item
Actions	GitHub's built-in automation and CI/CD
Ruleset	Modern replacement for branch protection rules; can be set at org/enterprise scope
CODEOWNERS	File that auto-assigns reviewers by file path
SCIM	Protocol that auto-creates and removes accounts from your identity provider
SSO / SAML	Single sign-on through your company identity provider
Innersource	Sharing code internally across the company, like open source but private

---

Sources

All statements above were checked against the official GitHub documentation:

• Repository roles for an organization — docs.github.com
• Roles in an organization — docs.github.com
• About repositories / repository visibility — docs.github.com
• About enterprise accounts — docs.github.com
• Abilities and restrictions of managed user accounts — docs.github.com
• Username considerations for external authentication — docs.github.com
• About teams (nested teams) — docs.github.com

Note: GitHub changes plans, pricing, and security product packaging frequently. Treat feature availability and pricing here as a guide and confirm the current details on docs.github.com before making decisions.