How to Make a GitHub Repository Public in 2026: A Practical Guide

Flipping a GitHub repository from private to public is surprisingly simple—it's just a few clicks in your repository's Settings, right in the Danger Zone. But that small action has massive implications, turning your team's private workspace into a public asset for the world to see, use, and contribute to.

This guide is for everyone involved in building products—founders, project managers, designers, and developers. We'll walk through exactly how to make a repo public, what to check before you do, and why it's a powerful move for any mobile app team.

Why Make a GitHub Repository Public?

Deciding to go public is a pivotal moment for any project. For a startup founder, it might be the day you share your minimum viable product (MVP) to get raw, honest user feedback. For a designer, it’s a chance to invite critique on a new interface from a global community. For developers, it's often the first step into the vibrant world of open-source.

But before you click that button, it’s crucial to understand what "public" really means on GitHub. This isn't just about visibility; it's a fundamental shift in how your project operates. A public repository lets anyone view your code, fork it to their own account, and suggest changes through pull requests.

Unlocking Collaboration and Visibility

Taking a repository public is a powerful move, especially if you're looking for collaboration. Suddenly, your project is searchable and discoverable by millions of developers on GitHub.com. Think about it: data from community discussions suggests that 67% of developers find new projects through GitHub's own search, which can lead to a 3x faster influx of contributors. You can see the data for yourself on GitHub.

By opening up your project, you're doing more than just sharing code. You're sending an invitation to a global pool of talent to help you build, test, and innovate. This collaborative energy can speed up development, uncover bugs you'd never have found, and bring in fresh ideas.

For example, a mobile dev team might open-source a custom React Native component they built. This not only builds goodwill but also attracts other developers who might use it, find bugs, and suggest improvements—freeing up the original team to focus on core product features.

To help clarify what changes, here's a quick breakdown of the key differences you should know.

Private vs. Public Repository: What Actually Changes?

This table lays out exactly what changes the moment you switch your repository's visibility. It's essential for everyone on the team, from PMs to founders, to understand these implications.

Making an informed decision is key. If you're still getting familiar with the basics, our guide on what a repository is on GitHub offers a great foundation before you open your work to the world.

How to Make a Repo Public (The Non-Technical Way)

If you're not living in the command line, the GitHub website is the most direct route to change a repository's visibility. It’s my go-to for quick updates, and it’s perfect for anyone on the team—from project managers to founders—who just needs to get the job done visually.

Everything you need is in your repository's Settings tab. Just head to your repo page on GitHub and click on "Settings," which you'll find on the far right of the navigation bar just below your repository's name.

Locating the Danger Zone

Once you're in the Settings, you'll need to scroll all the way to the bottom of the page. You can't miss it—GitHub cordons off the most critical, and potentially destructive, actions in a section outlined in red called the Danger Zone.

This is where you'll find the option to change your repository’s visibility. Look for "Change visibility" and click the button right next to it.

After you click, GitHub presents one final confirmation screen. Pay close attention to the warnings here; they spell out exactly what happens once you make the switch.

To finalize the change, you have to type out the full name of your repository, including your username (e.g., your-username/your-repo-name). It feels a little tedious, but this is a fantastic safety measure to prevent you from accidentally making the wrong repository public. Once you’ve typed it in, the "I understand, change repository visibility" button will light up. Click it, and the change is immediate.

Real-World Use Case: I’ve seen this put to great use by teams building mobile apps. A UI designer can make a design system repo public to sync it with a tool like RapidNative. This lets them generate a live preview of a React Native app with a simple QR code, allowing stakeholders anywhere to pop it open on their phones and give instant feedback on a real, working prototype. You can find more details in the official GitHub Docs.

Your Pre-Launch Security Checklist: What to Do Before Going Public

Flipping a private GitHub repository to public is a one-way street. Once you hit that button, your project's entire history—every single commit, comment, and file—is out there for good. Before you even think about making your repo public, you absolutely must run a thorough security audit.

This isn't just about what's in your code right now. It's about digging through the past. It’s surprisingly common for developers to hardcode secrets for convenience during the early days of a project, and those secrets are still buried in your Git history.

This diagram lays out the simple path to making a repo public through the GitHub UI. It's a common task, but one that deserves your full attention.

Notice how GitHub places this option in the "Danger Zone." They put it there for a reason, signaling that you need to be cautious before you click.

Scan and Scrub Your Commit History for Secrets

Your first and most critical task is to hunt down any sensitive data you might have committed by accident. I'm talking about API keys, database credentials, or private certificates that often end up in config files or even right in the source code.

It’s a common mistake to think, "I'll just delete the file and push the change." That doesn't work. Git's history saves everything, meaning anyone can just browse past commits and find the very secret you thought you removed.

To truly erase that data, you have to rewrite your repository's history. Tools like the BFG Repo-Cleaner or the officially recommended git-filter-repo were built for this exact purpose. They can search for and permanently strip specific files or text strings from every commit you've ever made.

For instance, if you realized you committed an .env file with your Stripe API key months ago, you’d use one of these tools to completely purge it from the repo’s history. This is the only way to ensure your new open-source project starts with a clean slate.

Audit Your .gitignore File

Think of your .gitignore file as your first line of defense against future slip-ups. It tells Git which files and folders to ignore, keeping them out of your commits entirely. Before going public, have your lead developer give it a final review to make sure it’s comprehensive.

A solid .gitignore for a mobile app project should always block:

• Environment Files: Make sure .env and other files holding sensitive variables are at the top of the list.
• Local Configurations: Exclude editor-specific folders like .vscode/ or .idea/ and pesky OS files like .DS_Store.
• Dependency Folders: Keep your repository lean by ignoring bulky package directories like node_modules/ or Pods/.
• Build Artifacts: Exclude compiled app files like .apk or .ipa.

Keeping your repository's history clean and its configuration tight is a fundamental development skill. For a deeper look at managing your codebase effectively, check out our guide on version control best practices.

For Developers: Using the Command Line to Go Public

If you're a developer, clicking through web UI settings feels like a detour. The command line offers a much faster, more direct path to managing repositories. It’s not just about speed; it's about integrating these tasks right into your development workflow.

The GitHub CLI: Your Go-To Tool

The official GitHub CLI (gh) is an absolute game-changer for this. Once you have it installed and authenticated, you can flip a repository from private to public with a single, straightforward command.

Just navigate into your local repository's directory and run this:

gh repo edit --visibility public

That's it. The change is immediate. I find this incredibly handy when I'm setting up a new open-source project and need to adjust visibility on the fly without breaking my focus.

Method Comparison: Web UI vs. GitHub CLI

Deciding between the website and the command line often comes down to your task. Here’s a quick breakdown to help you choose the right tool for the job.

For a one-off change, the UI is perfectly fine for anyone. But for developers who manage repos regularly or want to script their setup, the CLI is the clear winner.

Going Further with the GitHub API

When you need to manage repositories at scale—for example, making a dozen repos public after a product launch—the GitHub API is your best friend.

The real power here isn't just changing one repo; it's the ability to script these actions. A dev ops engineer can integrate repository management into CI/CD pipelines or admin scripts, saving hundreds of hours a year for large teams and ensuring every project follows the same rules.

You can use a simple tool like curl to send a PATCH request directly to the API endpoint.

Here’s a basic curl command to do the job. Just be sure to replace OWNER, REPO, and YOUR-TOKEN with your details.

curl \ -X PATCH \ -H "Accept: application/vnd.github.v3+json" \ -H "Authorization: Bearer YOUR-TOKEN" \ https://api.github.com/repos/OWNER/REPO \ -d '{"private":false}'

This approach is perfect for scripting. You could wrap this in a loop to process a whole list of repositories, making bulk updates a breeze.

Why Can't I Make My Repository Public? (A Guide for Teams)

When you’re working inside a company's GitHub organization, making a repository public isn't always as simple as clicking a button. If you've tried to change a repo's visibility but the option is grayed out or completely missing, don't worry—it’s not a bug. It’s almost always a permissions issue.

Most organizations intentionally limit who can make repositories public. This is a critical security measure to prevent anyone from accidentally exposing proprietary code, API keys, or other sensitive company data. So, if you can't find the setting, it's a strong signal that you’re not an organization Owner.

Understanding Your Role in the Organization

Your power to change a repository’s visibility is tied directly to your role. While these can be customized, here’s the typical setup for a product team:

• Members: This is the standard role for most developers, designers, and project managers. Members can usually create private repositories for their work but are almost always blocked from making them public.
• Owners: These are the admins with the keys to the kingdom—usually a CTO, lead engineer, or engineering manager. Owners have full control to change any repository's visibility and set the organization-wide policies that restrict other members.

In my experience, any organization with more than a handful of developers has these restrictions on by default. It's a simple but powerful guardrail that prevents a well-meaning teammate from accidentally open-sourcing a key internal tool.

If you’re a developer or PM who needs to make a project public, your first move isn't in the settings panel—it's starting a conversation. You'll need to find and contact one of your organization's owners. Not sure who that is? Our guide on how to add collaborators in GitHub can help you find who has admin-level access.

When you reach out, be ready to explain why the repository needs to go public. Is it a component you want to open-source? A public-facing demo for a new feature? Giving them clear context helps them understand the request and ensures the change aligns with company policy.

Frequently Asked Questions

Flipping the switch on a repository's visibility is a big step, and it's natural to have a few lingering questions. I've seen teams hesitate over these exact points, so let's clear up some of the most common concerns.

What happens to my repository stars?

When you make a private repository public, any existing stars and watchers are permanently removed.

It can feel like a setback, but this happens because those stars were tied to people who had private access. Think of it as a fresh start. Your project is now open to the entire GitHub community, giving you a chance to earn new stars from a much wider audience.

This is a one-time reset. From the moment you go public, all new stars are there to stay and will track your project's growing popularity.

Can I make my repository private again?

Absolutely. You can always change a public repository back to private. The process is just the reverse of making it public.

But here’s a big "gotcha" to be aware of: if anyone forked your repository while it was public, their forks remain public. You can't make them private or delete them. Those forks will exist as separate, public copies of your code, frozen at the moment you went private again. You also won't be able to merge changes from those public forks back into your now-private repo.

Why is the "Make Public" button grayed out?

If the option to change your repository's visibility is grayed out or missing entirely, the culprit is almost always a permissions setting within your GitHub Organization.

Organization owners have the power to block members from creating public repositories or switching private ones to public. It's a common security measure to prevent sensitive code from being accidentally exposed. If you run into this, you'll need to reach out to an organization owner. They can either make the change for you or grant you the necessary permissions to do it yourself.

Accelerate your team's journey from concept to code with RapidNative. Turn ideas, sketches, or product specs into production-ready React Native apps in minutes and iterate faster than ever before. Start building your mobile app today.