The Architecture of Visibility: Public, Private, and Internal Repositories

As a senior engineer, choosing a repository type isn’t just about who can see your code; it’s a fundamental decision regarding your security posture, collaboration velocity, and organizational culture. In the modern GitHub ecosystem, the lines between “open” and “closed” have blurred, giving way to sophisticated models like “Innersourcing.”

In my experience, many teams default to Private repos for everything proprietary, but they miss out on the massive productivity gains of Internal repositories. Internal repos allow everyone within a GitHub Enterprise account to view and contribute to code without needing explicit permission for every single project. This breaks down silos and encourages code reuse across departments.

The “Public” Pitfall: The biggest mistake I see isn’t making a repo public; it’s failing to implement secret scanning and branch protection before doing so. Once a secret is pushed to a public repo, it’s compromised forever, regardless of whether you delete the commit later. Conversely, the anti-pattern for Private repos is “Permission Bloat”—where developers spend more time requesting access to dependencies than actually coding. This is where the Internal type shines as the middle ground for enterprise scalability.

Study Guide: Repository Visibility & Permissions

Understanding repository types is essential for managing access control and ensuring that the right people have the right level of access to your codebase.

The Real-World Analogy

Think of repository types like different types of buildings:

Public: A public library. Anyone can walk in, read the books, and suggest improvements to the librarian.
Private: Your private home. Only people you explicitly invite can enter.
Internal: A corporate office building. Anyone with a company badge can enter any room, but the general public is kept out.

Core Concepts & Detailed Explanation

1. Public Repositories

Visible to everyone on the internet. Ideal for Open Source Software (OSS) and public portfolios.

Collaboration: Anyone can fork the repo and submit a Pull Request.
Cost: Usually free for standard features, including GitHub Actions minutes for OSS.
Security: Requires strict CODEOWNERS and branch protection to prevent unauthorized merges.

2. Private Repositories

Visible only to the owner and explicitly invited collaborators or teams.

Use Case: Commercial products, sensitive internal tools, or early-stage startups.
Workflow: Highly controlled. Access is usually managed via GitHub Teams.
Commands: gh repo edit --visibility private (using GitHub CLI).

3. Internal Repositories (Enterprise Only)

Visible to all members of the GitHub Enterprise account, but not to the public.

Innersourcing: Encourages developers in Team A to contribute to Team B’s project without manual onboarding.
Governance: Centralized control with decentralized contribution.

Real-World Scenarios

Scenario 1: The Solo Developer’s Side Project

Context: A developer building a new SaaS idea.

Application: Start with a Private repository. This prevents competitors from seeing the MVP and protects sensitive API keys during early development.

Why: It provides a safe sandbox. If the project gains traction and the dev wants to share a “lite” version, they can create a separate Public repo for the community.

Scenario 2: The Fortune 500 Engineering Org

Context: 5,000 developers across 50 different product lines.

Application: Use Internal repositories for shared libraries (e.g., a common UI kit or logging utility).

Why: It prevents “reinventing the wheel.” A developer in the Finance department can find and use a library built by the Retail department without filing a ticket for access.

Interview Questions & Answers

What is the primary difference between Private and Internal repositories?
Private repos are restricted to specific users/teams. Internal repos are visible to every member of the GitHub Enterprise account by default.
Can a forked repository have a different visibility than its parent?
Generally, no. A fork of a private repo must remain private. However, you can change the visibility of a repository manually if you have admin rights, but this is a destructive action for the fork relationship.
How do Public repositories impact CI/CD costs?
GitHub provides unlimited standard runner minutes for Public repositories to support the OSS community, whereas Private repos have monthly minute quotas based on the plan.
What is “Innersourcing” and which repo type supports it?
Innersourcing is applying OSS best practices (like open PRs and issues) within a company. Internal repositories are the primary enabler for this.
Why might you choose a Private repo over an Internal one in an Enterprise?
For sensitive projects like HR data tools, legal documents, or unannounced financial mergers where visibility must be strictly “need-to-know.”
How does GitHub handle secrets in Public repositories?
GitHub uses Secret Scanning to detect known patterns (like AWS keys). If found in a public repo, GitHub can automatically notify the provider to revoke the key.
What happens to a fork when a Public repo is made Private?
The forks are detached. GitHub usually deletes forks of a repo when it’s made private to prevent accidental data exposure, though this behavior varies based on the network structure.
Which repository type is best for a company’s “Core Product” code?
Private. It ensures the intellectual property is only accessible to authorized employees and prevents accidental leaks to the public.
Can an outside collaborator see an Internal repository?
No. Internal repositories are only visible to members of the Enterprise. Outside collaborators are not Enterprise members.
How do you programmatically change visibility for 100 repositories?
Use the GitHub CLI (gh) or the GitHub REST API/GraphQL API to iterate through the repos and update the visibility attribute.

Interview Tips & Golden Nuggets

The “Security First” Mindset: Always mention that visibility is the first layer of defense. Even in private repos, assume the “Zero Trust” model.
Enterprise Nuance: Mentioning “Internal” repos shows you have experience with GitHub Enterprise (GitHub AE or GHES), which is a huge plus for high-level roles.
The Forking Factor: Be ready to explain that forking is disabled for Internal repos by default in many organizations to keep code within the enterprise boundary.
Billing Awareness: Senior engineers care about costs. Knowing that Public repos get free GitHub Actions minutes shows you think about the company’s bottom line.

Comparison Table

Feature	Public	Private	Internal
Visibility	Anyone on Earth	Specific Users/Teams	All Enterprise Members
Cost (Actions)	Free / Unlimited	Plan-based Quota	Plan-based Quota
Best For	OSS, Portfolio, Docs	Proprietary IP, HR, Legal	Cross-team Collaboration
Searchability	Indexed by Google	Not Indexed	GitHub Internal Search Only

Repository Ecosystem Visualization

Scope of access: Global → Enterprise-wide → Team-specific

Branching Strategy

Public: Use Fork & PR to keep the main repo clean.
Private: Use Feature Branches within the same repo.
Internal: Hybrid approach allowed.

Collaboration

Public: Community driven, high volume of issues.
Private: Restricted to assigned squad members.
Internal: Open to any employee; high discovery.

Security

Public: Secret scanning is mandatory.
Private: 2FA and SSO enforcement required.
Internal: Audited by Enterprise admins.

Decision Guidance: Which one to pick?

Is this for the general public or OSS? → Public
Is this sensitive company IP for a specific team? → Private
Is this a tool that could benefit other teams in your company? → Internal

Production Use Case: “The Shared UI Library”

Context: A company has 10 different web apps. Each app was building its own buttons and headers.

Implementation: The Design Systems team created an Internal repository for a React Component Library. They enabled Discussions and Issues for everyone in the company.

Result: Developers from the “Payments” team found a bug in the header, submitted a PR to the Internal repo, and fixed it for all 10 apps simultaneously. This saved approximately 40 engineering hours per month.