Great question—scaling repo organization in a startup while avoiding GitHub Enterprise costs is a super common pain point. Since nested sub-organizations are only available in Enterprise, here’s a practical, low-fuss approach using built-in free/team tier features to mimic your desired hierarchy:

1. Standardize Repository Naming Conventions #

First, enforce a consistent naming scheme to group repos logically in your main organization:

• Common API repos: Keep them simple or add a clear prefix like common-api- (e.g., common-api-auth, common-api-core). This keeps all shared APIs grouped together in the repo list.
• Client-specific repos: Use a uniform structure like client-[client-id/name]-[platform], e.g., client-acme-web, client-acme-mobile, client-beta-mobile. When sorted alphabetically, all repos for a single client will cluster together, making them easy to find.

2. Use GitHub Teams for Centralized Permissions #

Since your entire team needs access to all repos, streamline permissions with teams:

• Create an All-Team group and add every team member to it. Assign this team Read (or Write, if everyone needs edit access) permissions across all repos—this avoids manually setting permissions for each user on 23 repos.
• Optional: For finer control, create sub-teams like API-Maintainers or Client-Acme-Team to assign elevated permissions (e.g., Admin) to specific repo groups, while keeping All-Team with base access.

3. Leverage GitHub Projects for Visual Hierarchy #

To add a visual layer of organization beyond just names:

• Create a top-level project titled Client Repo Dashboard
• Add a column for each client (e.g., "Client Acme", "Client Beta")
• Link each client’s web/mobile repo to the corresponding column
• Create a separate project or column for your common API repos
  This lets anyone on the team quickly navigate to all repos for a client without scrolling through the full org repo list.

4. Optional: Add CODEOWNERS for Clear Accountability #

For each repo, add a CODEOWNERS file to specify which team owns maintenance:

• For common API repos: * @your-org/api-maintainers
• For client repos: * @your-org/client-acme-team
  This ensures PRs get routed to the right people, even without Enterprise-level repo governance tools.

Key Notes #

• Nested sub-organizations are an Enterprise-only feature, so this naming+teams+projects approach is the closest you’ll get to your desired "clientX path" structure without upgrading.
• Sticking to strict naming conventions will make search work in your favor—just type client-[name] in the org repo search bar to pull up all repos for that client instantly.

内容的提问来源于stack exchange，提问作者user7875136