Skip to main content
In this lesson you’ll create a parent team and a nested child team in the Game Dev Studio organization, then grant repository access to demonstrate how team membership and repository permissions are managed. This walkthrough assumes you are signed in as an organization admin. Prerequisites
  • Admin access to the GitHub organization.
  • A target repository (in this example, app-backend) already created and accessible.
Steps overview
  1. Create a parent team (PC Devs).
  2. Grant the team access to a repository.
  3. Create a child team (Windows Client) under the parent.
  4. Observe permission inheritance and manage members.
  1. Create the parent team (PC Devs)
Create a new team called “PC Devs” in the organization. Leave the identity provider group association at the default settings if you don’t need to integrate an IdP group right now.
A screenshot of a GitHub organization team page for "PC-Devs" in dark mode, showing the team's avatar and an "About" section. The right side lists one member with a search box and a green "Add a member" button.
  1. Grant repository access to the team
A newly created team has no repository access by default. To give the PC Devs team access to a repository (for example, app-backend) open that repository, navigate to Settings → Collaborators and teams, then add the team and select the desired permission level (Read, Write, or Admin). In this demo we grant the PC Devs team Write access and confirm by clicking Add selection.
A screenshot of a GitHub repository's Settings → Collaborators and teams page in dark mode, showing the repository is private and a "PC-Devs" team has been granted write access. The page displays access sections (Base role, Direct access, Organization access) and controls to add people or teams.
After adding the team, it will appear in the repository access list. This makes it easier to audit which teams have access to each repo.
  1. Create a nested (child) team under PC Devs
Back on the organization teams page, create a child team and set the parent to PC Devs. In this example the child team is named “Windows Client.”
A GitHub organization page (game-devstudio) showing the "Create new team" form with the Team name filled as "Windows-Client" and the Parent team dropdown set to "PC-Devs." The screenshot is in dark mode inside a browser window with tabs visible.
Because the Windows Client team is nested under PC Devs, it inherits the parent team’s repository permissions. In this demo, since PC Devs has Write access to app-backend, Windows Client also has Write access by inheritance.
Child teams inherit repository access from their parent teams. Permissions are additive: a child team receives at least the access level the parent grants and can be given additional repository permissions, but it does not reduce the parent’s access.
Be cautious when granting elevated permissions (Write or Admin) at a parent-team level — those permissions propagate to all child teams. Review team membership before applying wide-scoped access.
Recommended practices
  • Grant repository permissions at the appropriate level: prefer granting access at a parent team when many subteams need the same base permission, but use child teams to restrict or add permissions for specific groups.
  • Keep team membership tight and review maintainers regularly to avoid privilege escalation.
  • Use GitHub’s audit logs and the repository access pages to confirm who has access.
Quick reference Links and references You can repeat these steps to create additional child teams (for example, macOS Client or Android Client) to reflect your org structure and assign repository permissions at the right level as your organization grows. Use each team’s page to add members, invite maintainers, and fine-tune access.

Watch Video