GitHub 22 🌐 Managing GitHub Organizations, Teams, and Permissions - KandZ

⏱️ Estimated read: 10 min | |

An organization is a shared account where businesses and open-source projects manage many repositories at once. It is not a user account and it does not own code directly—it owns repositories, and access to those repositories is granted to people and teams through a layered permission model. The LFCS/GitHub exam tests this hierarchy: organization roles control administrative actions, repository roles control code access, and teams act as the bridge that applies repository access to groups of people. Confusing these layers is the most common source of permission errors.

Key point: Organization roles (Owner, Member, Billing manager) govern what someone can do in the organization. Repository roles (Read, Write, Admin) govern what someone can do in a specific repository. Teams are groups of members that receive repository roles, and nested teams inherit the parent team’s access.

Why organizations, teams, and permissions exist

The scaling problem. A personal account can own repositories and grant access to collaborators one by one. This works for a single project with two collaborators. It does not work for an organization with fifty repositories and two hundred developers. Organizations provide a central identity, a central billing relationship, and a permission model that scales through teams and roles .

The role separation problem. Not everyone needs the same access. A finance manager needs to view billing, not push code. A security engineer needs to see alerts across all repositories, not manage team membership. A contractor needs to write to one repository, not read every repository in the organization. GitHub separates organization-level permissions from repository-level permissions so that each role grants only what the responsibility requires .

The team inheritance problem. Managing individual access for two hundred developers across fifty repositories produces ten thousand permission entries. Teams reduce this: a developer joins the backend team, the backend team has Write access to the api repository, and the permission is applied through the team membership. When the developer leaves the team, the access is removed automatically. Nested teams extend this: a child team inherits the parent team’s repository access, so granting Engineering Write access to a repository also grants Frontend and Backend (child teams) that same access .

The outside collaborator problem. Not everyone who contributes is an organization member. An outside collaborator is a person who has access to specific repositories but is not a member of the organization. They cannot be added to teams, they do not appear in the organization member list, and their access is managed repository by repository. This distinction matters for billing and for security audits .

The trade-off. The layered model is powerful but requires discipline. A team can inherit access from a parent, a repository can grant access to a team, and an organization role can grant access to all repositories. When a permission problem occurs, the cause can be at any layer—the organization role, the team hierarchy, or the repository setting. The exam tests the ability to trace access through these layers.

a. Organization roles: Owner, Member, and specialized roles

Organization roles are assigned at the organization level. The two default roles are Owner and Member. Owners have full administrative control: they can invite members, remove members, delete teams, access the audit log, and manage billing . Members have standard access: they can create repositories (if the organization allows it), create teams, and view other members .

Specialized roles grant specific administrative capabilities without full owner control. The Billing manager can view and manage billing settings but cannot manage repositories. The Security manager can manage security policies and alerts across all repositories. The CI/CD admin can manage Actions policies, runners, and secrets. These roles are assigned to existing members, not chosen at invitation time .

Organization roles are separate from repository roles. An organization Owner has admin access to every repository by default, but a Member may have no repository access at all until a repository role is granted .

b. Repository roles: Read, Triage, Write, Maintain, Admin

Repository roles are assigned per repository. The five roles form a ladder from least access to most access .

Role	Recommended For	Key Permissions
Read	Non-code contributors	View code, open issues, comment
Triage	Issue managers	Apply labels, assign issues, manage PRs without writing code
Write	Active contributors	Push to repository, merge PRs, edit wikis
Maintain	Project managers	Manage repository settings without destructive actions
Admin	Full control	Delete repository, manage access, manage security

The critical distinction for the exam is the line between Read and Write. A Read user can open issues and submit pull requests from forks, but cannot push directly to the repository. A Write user can push and merge. A Triage user sits between: they can manage issues and pull requests without the ability to push code .

Repository roles can be assigned directly to individuals, to outside collaborators, or to teams. When assigned to a team, every member of that team receives the role. When a person is removed from the team, the role is revoked automatically.

c. Teams and nested inheritance

A team is a group of organization members. Teams can be visible (everyone in the organization can see them and @mention them) or secret (only team members and owners can see them). Secret teams cannot be nested .

Nested teams are the mechanism for inheritance. A parent team can have multiple child teams. When a parent team is granted a repository role, every child team inherits that role. For example: Engineering (parent) has Write access to api. Backend (child of Engineering) also has Write access, even though no one granted it directly. A member of Backend can push to api because of the inheritance chain .

To change access for a child team, you must change the parent team’s access, unless the child team has direct access that overrides the inherited access. Removing a parent team’s access removes it from all child teams. This is the cascading behavior that makes nested teams efficient and dangerous: a single change at the top affects every team below .

Teams are also the target of CODEOWNERS. A team can be listed as the owner of a path, and when branch protection requires code owner review, the team’s approval becomes mandatory. This connects the permission model to the review workflow.

Complete Example Session

# ============================================
# PART 1: CREATE A TEAM
# ============================================

# Navigate to Organization → Teams → New team
# Name: backend
# Parent team: Engineering
# Visibility: Visible
# Create team

# ============================================
# PART 2: ADD MEMBERS TO THE TEAM
# ============================================

# Team page → Add a member
# Search for user and select role: Member
# Repeat for each developer

# ============================================
# PART 3: GRANT TEAM ACCESS TO A REPOSITORY
# ============================================

# Repository → Settings → Collaborators and teams
# Add teams → select "backend"
# Permission: Write
# The team's members now have Write access.

# ============================================
# PART 4: OBSERVE INHERITANCE
# ============================================

# Engineering (parent) has Write access to "api".
# Backend (child of Engineering) inherits Write.
# Adding a new child team "frontend" to Engineering
# automatically grants it Write to "api".

# ============================================
# PART 5: ASSIGN AN ORGANIZATION ROLE
# ============================================

# Settings → Organization roles → Role assignments
# New role assignment
# User: security-lead
# Role: Security manager
# The user can now manage security alerts across all repos.

# ============================================
# PART 6: VERIFY ACCESS
# ============================================

# As a Backend team member, attempt to push:
git clone https://github.com/org/api.git
cd api
git commit --allow-empty -m "Test push"
git push origin main
# Push succeeds because of inherited Write access.

# ============================================
# PART 7: REMOVE TEAM ACCESS
# ============================================

# Repository → Settings → Collaborators and teams
# Select "backend" → Remove
# If Backend had direct access, it is removed.
# If inherited from Engineering, remove from Engineering.

# ============================================
# PART 8: OUTSIDE COLLABORATOR
# ============================================

# Repository → Settings → Collaborators and teams
# Add people → enter email or username
# Permission: Read
# The person is not an organization member and cannot join teams.

# ============================================
# PART 9: AUDIT ACCESS
# ============================================

# Organization → Settings → Audit log
# Filter by "team.add_member" or "repo.access"
# Review who has access to what.

The nine parts trace the permission model: creating a team, adding members, granting repository access, observing inheritance, assigning an organization role, verifying push access, removing access, adding an outside collaborator, and auditing.

Quick Reference

Organization Roles

Role	Key Permissions
Owner	Full control, all repositories, billing, audit log
Member	Create repos, create teams, view members
Billing manager	View and manage billing only
Security manager	Manage security alerts and policies
CI/CD admin	Manage Actions runners, secrets, policies

Repository Roles

Role	Push	Merge PR	Manage Access
Read	No	No	No
Triage	No	No	No
Write	Yes	Yes	No
Maintain	Yes	Yes	No
Admin	Yes	Yes	Yes

Team Types

Type	Visibility	Nesting
Visible	All org members	Yes
Secret	Team members + owners only	No

Best Practices

✅ Do This:

# Use teams for repository access
<!-- Scales without individual entries -->            # ✅

# Use nested teams for inheritance
<!-- Child teams inherit parent access -->            # ✅

# Assign the minimum repository role
<!-- Read for viewers, Write for contributors -->     # ✅

❌ Don’t Do This:

# Grant Admin to everyone
<!-- Destructive actions become possible -->         # ❌

# Use secret teams for nested structures
<!-- Secret teams cannot be nested -->               # ❌

# Rely on organization roles for repository access
<!-- Owners have access, Members may not -->         # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
User cannot push despite team access	Team inherited from parent, parent lacks Write	Grant Write to parent team
Removed team still has access	Inherited from parent	Remove from parent team
Outside collaborator cannot join team	Outside collaborators cannot be team members	Grant repository access directly
Secret team cannot be nested	Secret teams cannot have parents	Use visible team for hierarchy
Owner has access to all repos	Organization role grants it	Expected behavior; use repository roles to restrict Members

Real-World Examples

1. Create Team

Organization → Teams → New team → backend

2. Grant Repository Role to Team

Repository → Settings → Collaborators and teams → Add team

3. Assign Organization Role

Settings → Organization roles → Role assignments → New assignment

4. Add Outside Collaborator

Repository → Settings → Collaborators and teams → Add people

5. Nest a Team

Team settings → Parent team → Select parent

6. Verify Access

git push origin main

7. Remove Team from Repository

Repository → Settings → Collaborators and teams → Remove

8. Audit Access

Settings → Audit log → Filter by action

9. Check Team Members

Team page → Members

10. Check Repository Role

Repository → Settings → Collaborators and teams → View permission

Visual

Permission Hierarchy

┌──────────────────────────────────────────────┐
│  ORGANIZATION                                │
│  Roles: Owner, Member, Billing, Security     │
│  (controls administrative actions)           │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  TEAMS                                       │
│  Visible or Secret                           │
│  Nested (parent → child inheritance)         │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  REPOSITORY ROLES                            │
│  Read, Triage, Write, Maintain, Admin        │
│  (controls code access)                      │
└──────────────────────────────────────────────┘

Each layer answers a different question: what can you do in the org, what group are you in, what can you do in the repo.

Nested Team Inheritance

Engineering (parent)
├── Backend (child)
├── Frontend (child)
└── Mobile (child)

Grant Engineering Write to "api" → Backend, Frontend, Mobile all get Write.
Grant Backend Admin to "api" → Backend has Admin (overrides inherited Write).
Remove Engineering from "api" → All children lose inherited access.

The parent’s access is the floor. Child teams can have more, but not less.

Summary

Item	Value
Organization roles	Owner, Member, Billing, Security, CI/CD
Repository roles	Read, Triage, Write, Maintain, Admin
Team inheritance	Child inherits parent’s repository access
Secret teams	Cannot be nested
Outside collaborator	Not an org member, access per repository
Admin repository role	Required to manage access
Owner organization role	Admin access to all repositories

Key takeaways:

Organization roles and repository roles are separate layers. An Owner has admin access to every repository, but a Member may have no repository access until a role is granted .
Teams are the scaling mechanism. Repository access granted to a team applies to every member. Nested teams inherit the parent’s access, so a single grant at the top cascades down .
The five repository roles form a ladder. Read (view), Triage (manage issues), Write (push), Maintain (manage settings), Admin (delete and manage access) .
Outside collaborators are not team members. They cannot be added to teams. Their access is managed repository by repository .
Removing a parent team’s access removes it from all children. If a child team has direct access, that must be removed separately. The inheritance is a floor, not a ceiling.

Remember: The permission model is a hierarchy of questions. Organization roles answer “what can you administer?” Teams answer “who are you grouped with?” Repository roles answer “what can you do to this code?” The exam tests the ability to trace a permission from the person to the team to the repository, and to identify which layer is granting or denying access.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!