Before we can talk about public versus private, we need a clear picture of what’s actually being made visible or hidden.

What is a repository?

A repository, often shortened to “repo,” is a project folder that Git is tracking, along with its entire saved history — every snapshot, every message, every past version of every file. When people talk about “a project on GitHub” or “a codebase,” they usually mean a repository hosted somewhere online, where team members or the public can view it, download it, or contribute to it.

What does visibility control?

Visibility is a setting attached to a hosted repository that determines who is allowed to see its contents at all. It answers one very simple question: if a stranger on the internet finds the link to this repository, can they open it and read the code, or are they blocked entirely? This is a separate concept from permissions like “who can edit” — visibility is the very first gate, deciding whether someone can even look inside before any question of editing comes up.

A public repository is the “glass-walled lobby” — visible to literally anyone with an internet connection.

When a repository is marked public, its code, its full commit history, its issues, and typically its discussions become visible to any person, anywhere in the world, whether or not they have an account on the hosting platform. Search engines can index public repositories, meaning someone could stumble onto your code simply by searching for a phrase that appears in it. There is no login wall between a curious visitor and your source code.

What “public” does not automatically mean

Being public does not mean anyone can change your code directly. Visibility and editing rights are separate settings. A public repository is usually still protected so that only the owner and explicitly trusted collaborators can push changes directly, while outside visitors can only view the code, or propose changes through a formal review process that the owner must approve.

A private repository is the “locked office” — invisible to everyone except people explicitly granted access.

When a repository is marked private, it effectively disappears from view for everyone except the owner and anyone the owner has specifically invited. Search engines cannot see it, random visitors get a “not found” style message rather than a peek at the code, and even the existence of the repository can be hidden from people without access, depending on the platform’s settings.

Who typically gets access to a private repository

Access to a private repository is granted individually or through a team, and each person can usually be given a different level of permission — for example, someone might be allowed to view and read the code, while another person is allowed to make changes, and a third person is given full administrative control over the repository’s settings.

Placed side by side, the practical differences become much easier to see clearly.

Visibility decides who can see a repository at all — but once someone is let in, different people can still have very different levels of access.

flowchart TD
    A["Person requests to view a repository"] --> B{Is the repository public?}
    B -- Yes --> C["Anyone can view the code"]
    B -- No --> D{Has this person been invited?}
    D -- Yes --> E["Access granted, at their assigned level"]
    D -- No --> F["Access denied / repository not visible"]
    style A fill:#fafafa,stroke:#e5e5e5
    style C fill:#111111,stroke:#111111,color:#ffffff
    style E fill:#111111,stroke:#111111,color:#ffffff
    style F fill:#fef2f2,stroke:#dc2626
        

Common access levels within a repository

Most hosting platforms allow the owner to assign different roles to different collaborators, even within a private repository. A read-only role can view code and history but cannot change anything. A write or contributor role can make and submit changes. An administrator or owner role can manage settings, including visibility itself, and control who else is invited.

Choosing the wrong visibility setting is one of the most common, and most damaging, mistakes a beginner can make.

Because a repository stores its complete history forever, making a repository public exposes not just the current state of the code, but every past version too — including anything that was ever committed, even if it was later deleted from the latest version. This matters enormously if sensitive information, such as passwords, private keys, or internal business details, was ever accidentally committed at any point in the project’s past.

The right choice depends heavily on the purpose of the project and who it’s meant to serve.

These mistakes come up constantly among beginners, and even experienced teams occasionally slip up.

A handful of consistent habits make it much less likely you’ll ever expose something you didn’t mean to.

The public-versus-private decision plays out at massive scale across the software industry every single day.

Enormous, widely used open-source projects — the kind that power much of the modern internet — are built entirely on public repositories, where anyone can inspect the code, report problems, or contribute fixes. At the same time, the vast majority of commercial software running inside companies lives in private repositories, invisible to anyone outside the organization, precisely because that code represents competitive, proprietary value.

Yes, an owner or administrator can typically switch a repository between public and private at any time, though switching to public should always be preceded by a careful review of the full history.

Only people the owner has explicitly invited, along with anyone given administrative access to the account or organization, can see a private repository’s contents.

On most major hosting platforms, public repositories are free to host, since sharing code openly aligns with the platform’s broader purpose; private repositories may sometimes come with different limits or pricing depending on the platform and plan.

No. Visibility only controls who can see the code. A license is a separate legal document describing what people are legally allowed to do with that code, such as reuse, modify, or redistribute it.

Some platforms allow certain related features, such as internal discussion boards, to remain restricted even when the main repository is public, but this depends entirely on the platform and should never be assumed by default.

On most platforms, a direct copy of a public repository is required to remain public as well, though some platforms and account types allow copying the code into a separate, newly private repository.

Repository visibility is the very first gate standing between your code and the outside world, deciding whether a project is a glass-walled lobby open to anyone, or a locked office reserved for people you’ve personally invited in. Public repositories invite openness, collaboration, and scrutiny, making them the natural home for open-source projects and public portfolios. Private repositories protect confidentiality and control, making them the natural home for proprietary products and unfinished work. Neither choice is inherently better — the right setting depends entirely on what the project contains and who it’s meant to serve, and thoughtful teams revisit that choice deliberately as a project grows.