Public vs Private Software Repositories

TL;DR

• Public repositories: Anyone can view, clone, and fork the code, but only authorized collaborators can write directly to the repository.
• Private repositories: Access is limited to the owner, invited collaborators, and authorized organization members.
• Internal repositories: Enterprise members can discover and reuse code without exposing it publicly.
• Best for open source: Use a public repository when community discovery, contributions, and transparency are priorities.
• Best for proprietary code: Use a private repository to restrict access to commercial code, client work, roadmaps, and other sensitive assets.
• Best for enterprise innersource: Use an internal repository to support cross-team reuse while keeping code inside the enterprise.
• Collaboration: Public and private repositories can both support unlimited collaborators, but advanced private-repository features may require a paid GitHub plan.
• Forking: Public repositories can be forked by anyone. Private and internal repository forking depends on access rights and organization policies.
• Security: Private visibility reduces exposure but does not replace MFA, access reviews, secret scanning, Dependabot, push protection, or code scanning.
• Visibility changes have consequences: Copies that were already cloned or forked may remain outside your control after changing a repository from public to private.
• Enterprise distinction: Repository visibility controls access to an individual project, while GitHub Enterprise Server private mode controls authentication across the entire installation.
• Recommended default: Organizations should generally create repositories as private and make selected projects public only after a security and content review.

When you flip a GitHub repository from public to private or vice versa, you change four things at once:

• Who can view your code
• Who can clone or fork it
• Who can contribute to it
• How exposed you are to security risk

This article discusses these four changes tier by tier, so you can pick the right setting confidently, with control over what you are doing.

On a general note, the right settings should facilitate developer collaboration while protecting proprietary intellectual property.

What Is a Repository? (Definition & Basics)

GitHub defines a repository as:

A repository is the most basic element of GitHub. It’s a place where you can store your code, your files, and each file’s revision history. Repositories can have multiple collaborators…

Think of a repository as a digital container that stores your code, files, and every revision made to them. It also enables multiple collaborators to work on the same codebase at the same time, such as employees in an organization assigned to a specific project. Revisions are tracked through Git version control, which records every change, who changed it, and when. Git also lets developers create separate branches for their work and then merge them into the main branch, so that changes made by others are not overwritten.

A repository has one basic setting that defines almost all its characteristics: visibility. You can set it to one of the following:

• Public
• Private
• Internal

Visibility decides how open or restricted your files are to the rest of the world, like who can view your work, copy it, and change it. Choose a visibility level for your repo carefully from the very start. Though you can switch it later, it has consequences for anyone who has already forked or cloned your project.

Repository Terminology

Before using GitHub and its repositories, let’s look at the definitions for the most common terms.

Repository Ownership (Personal vs Organization)

Every repository belongs to either a personal account or an organization.

• A personal-account repo has one owner with total administrative control over it. The owner can manually invite individuals to collaborate.
• Organization repositories are owned by the organization itself, rather than any single person. Organization owners own all repos belonging to the organization. Responsibility for managing a repo is shared by different individuals in an organization.

In both cases, access to a repository is managed through permissions. GitHub uses different permission systems for each ownership type.

• For a personal-account repository, GitHub provides two permission levels: the repository owner and To understand the access rights for each level, visit Permission levels for a personal account repository.
• For an organization-owned repository, GitHub uses roles that represent different levels of access: Read, Triage, Write, Maintain, and Admin. Organization owners can assign roles to teams as well as individuals (including outside collaborators). That way, for example, you can grant Write access to the entire engineering team in one move instead of granting it to each team member one by one. For more on roles, see Repository roles for an organization.

Enterprise Accounts and Repo Ownership

Enterprise accounts deserve a mention here. An enterprise account enables a business to manage multiple organizations from a central point. The structure looks like this:

• An enterprise account is your top administrative boundary. With it, you can centrally manage policy and billing for multiple organizations.
• Inside it, you can have one or more organizations.
• Inside each organization, you manage repositories, teams, members, and settings.

Enterprise accounts are managed through roles. There are several predefined roles (like Enterprise owner, App manager), with the ability to define custom roles. For details, see Abilities of roles in an enterprise.

Collaboration on Public vs Private Repos

GitHub Free is more generous with public repositories than private ones.

• On a free personal or organization account, you get unlimited collaborators on unlimited public repos, with the full feature set.
• Switch to private, and you still get unlimited repositories and unlimited collaborators, but the feature set is limited. For advanced private repo tooling, like protected branches, page hosting, wikis, and multiple pull request reviewers, you need GitHub Pro, Team, or Enterprise Cloud.

Here is a quick look at what each plan includes:

*Do not confuse with an enterprise account. GitHub Enterprise is a plan that you can purchase with an enterprise account.

Read Also: The Hidden Risk of Wrapped Dependencies: When Your Vendor’s Vendor Changes the Rules

Read Also: The Hidden Costs of Community-Maintained Software Repositories

Repository Visibility Options (Public, Private, Internal)

You can set the visibility of a repo to one of the following:

• Public

Setting the visibility of a repo to public means that anyone on the internet, signed in or not, can view, clone, and fork the repository. However, they cannot push changes directly. To contribute to a public repo, changes have to be approved via a pull request. The process looks like this: someone forks your code, makes changes on their copy, and creates a pull request that asks you to merge it back. You stay in control of what lands in your codebase.

• Private

Setting visibility to private means that only you, people you explicitly share access with, and certain members of your organization (this one in case of organization repos) can access the repo. Non-collaborators can’t view files, issues, or anything else in the repository.

• Internal

This visibility level is available for repositories in organizations that use GitHub Enterprise Cloud with an enterprise account. In fact, it is the default setting for all new repositories created in an organization owned by an enterprise account. According to Github docs:

“Organization members have read permissions to all internal repositories in an enterprise, including those in organizations they are not a member of. Internal repositories are not visible to people outside of the enterprise, including outside collaborators on organization repositories.”

An internal repo is built for innersource, allowing members to collaborate using open source methodologies without sharing proprietary information publicly.

By default, enterprise members can fork an internal repository into any organization where users can create repositories. Organization owners can also allow users to create a fork owned by a user account. Enterprise owners can manage the forking policy for some or all organizations within an enterprise.
Members of the enterprise account can’t edit the repository’s code directly, but they can fork the repository and create a pull request from their fork.

It is important to note that

They’re visible to any user on your GitHub Enterprise instance, so you can benefit from a collaborative community.

Private repositories require a little more setup. They’re only available to you, the repository owner, as well as any collaborators you choose to share with.

Private Mode for the GitHub Enterprise instance is a different concept than Public/Private settings for a Repository.

In private mode, GitHub Enterprise requires every user to sign in to access the installation. Anonymous clones over git:// are disabled and—if built-in authentication is enabled—new users can’t sign up and must be invited by an administrator.

So the private mode setting really means that users must log in to access the instance. If your GitHub Enterprise instance is on a public-facing IP, it needs to have private mode enabled.

Public and Private repositories will still affect visibility/access to users that belong to an Organization, Team, or Repository.

Public Repositories : They’re visible to any user on your GitHub Enterprise instance.

Private Repositories : They’re only available to the repository owner. You can add collaborators of your choise to share with.

You can keep all the repositories in your organization’s GitHub Enterprise to Private by default with exception to a few repositories which contain sensitive information. This is a good way to keep reusing the code in the same organization. If you have a repository you want made Public instead of Private you can request to your GitHub Enterprise to white-list it.

One distinction worth clearing up, because it trips people up constantly: repository visibility is not the same thing as GitHub Enterprise Server’s private mode. Visibility is a per-repository setting. Private mode is an instance-wide setting that an administrator turns on for an entire GitHub Enterprise Server installation, forcing every user to sign in before accessing anything on it, including public repositories. You can have a public repository sitting on a server that’s in private mode. The repository is still marked public, but nobody outside your network can reach the server to see it, unless anonymous Git read access has separately been enabled. Visibility controls the repository. Private mode controls the server.

Choosing a visibility tier sets the baseline for who can interact with your intellectual property. Public repositories are visible to anyone globally, meaning any internet user can view, clone, and fork the codebase, though they cannot write data or merge code without an approved pull request. Private repositories lock down access completely, ensuring non-collaborators cannot see the source code, open issues, or exposed project roadmaps. For complex corporate structures, a third option exists: Internal repositories. Available exclusively to organizations using GitHub Enterprise Cloud or GitHub Enterprise Server, internal repositories allow any member of the broader enterprise to view and clone the project, breaking down development silos while keeping the code safe from the public internet.

It is vital to explicitly separate “repository visibility” (public, private, or internal) from GitHub Enterprise’s instance-level “Private Mode.” While repository visibility dictates access to an individual project, Private Mode is a global appliance setting that requires authentication just to hit the landing page of an entire on-premises or cloud instance, hiding the server entirely from unauthenticated traffic.

To determine exactly how these settings govern user access, developers can reference this comprehensive Visibility Tiers Comparison Table:

Which Visibility Fits Your Project?

Definitions only get you so far. Here’s how the three tiers map to situations you’ll actually run into.

• Open-source project: go public. You want strangers to find the code, fork it, and send pull requests. Your code, issues, and history are visible to everyone, so treat any secrets or credentials accordingly.
• Solo learning repo: public usually works well here too, mostly because it costs nothing extra and doubles as a portfolio. Keep it private only if you’re following paid course material under a license that restricts redistribution.
• Proprietary codebase: private, without much debate. You control exactly who can view and clone it, and non-collaborators can’t see the code or any secrets stored in it.
• Enterprise innersource: internal. You want the whole company to browse, learn from, and reuse code across teams without exposing any of it outside the organization. This is the tier most comparisons skip, and it’s the one that solves the problem of wanting internal sharing without internal secrecy.

Security Considerations for Repository Visibility

Visibility is the biggest security lever you have on GitHub, so treat it that way.

Public repositories expose your entire codebase to anyone who wants to look, which raises the odds that someone finds and exploits a vulnerability, or stumbles on sensitive information you forgot to remove. GitHub gives you several tools to close that gap: Dependabot for vulnerable dependencies, secret scanning to catch exposed credentials, push protection to stop secrets before they’re committed, code scanning for vulnerable patterns in your code, and a SECURITY.md file that tells people how to report problems responsibly.

Private repositories restrict who can see your code, but that’s not the same as being secure by default. You still need multi-factor authentication on every account with access, tightly scoped access controls, and regular audits of who actually has permission to be there. The most common failure mode with private repos isn’t a stranger breaking in. It’s a leaked API key or credential sitting in a commit history that a collaborator’s compromised account can reach.

Neither tier removes the need for the other’s precautions. A public repo still benefits from access controls on who can merge changes, and a private repo still benefits from automated scanning that catches a hardcoded secret before it ships. Treat visibility as one layer of a security posture, not the whole thing.

One governance pattern worth adopting if you’re running an organization: default every new repository to private, then whitelist specific repos to public only after someone reviews them. GitHub supports this directly, letting an organization or enterprise owner set a default repository visibility and restrict members from creating public repositories at all. It’s a lot easier to promote one project to public deliberately than to notice too late that something sensitive went public by default.

Whatever the visibility, organization owners always retain access to every repository in the organization, and only admins can change a repository’s visibility after the fact.

Read Also: The Hidden Risk of Wrapped Dependencies: When Your Vendor’s Vendor Changes the Rules

Read Also: The Hidden Costs of Community-Maintained Software Repositories

Action1 Brings you Private Third-Party Application Packages

Organizations do not have to choose between the broad accessibility of public repositories and the security, control, and consistency of private software distribution. Action1 provides a continuously updated, privately maintained Software Repository in which third-party application packages are sourced, tested, scanned for malware, and validated before publication. This reduces the risks associated with outdated, unverified, or community-maintained packages while giving IT teams ready-to-deploy updates for commonly used business applications. When an application is not available in the built-in catalog, administrators can create organization-specific custom packages for third-party or proprietary software, maintain multiple versions, define installation requirements, and distribute them to selected Windows and macOS endpoints. Centralized scheduling, deployment status, compliance reporting, offline-device retries, and bandwidth-efficient peer-to-peer distribution then help ensure that approved applications remain consistently installed and updated across the environment. By combining a trusted vendor-managed catalog with customizable private packages, Action1 gives organizations the convenience of a public repository without sacrificing software governance, package integrity, or deployment control.

Action1 is free for up to 200 endpoints. Forever. Watch the demo to see it in action. Or sign up in five minutes and start patching and deploying software right now.