Bringing someone in to review your code is one of the smartest things you can do before a launch — but it raises a fair question: how do you let a reviewer read your code without handing them the keys to change, delete, or take over the whole project? The goal is simple: enough access to look, and nothing more. Here's how to do that on GitHub, in plain English.
Almost everything here comes down to one thing — who owns the repository — because GitHub handles permissions very differently depending on the answer.
First: who owns the repo?
There are two common kinds of owner. A personal repository belongs to one GitHub user account — its address looks like github.com/yourname/your-app. An organization repository belongs to a GitHub organization or business account — github.com/your-company/your-app. The difference matters more than you'd think, because GitHub gives organizations far more control over who can do what.
The catch with private personal repos
Here's the part that surprises people. A repository owned by a personal account really only has two levels of access: owner, and collaborator. And on a private personal repo, a collaborator gets write-style access — they can push changes — not true read-only. GitHub simply doesn't offer a 'just looking' role for collaborators on personal repos.
If your repo is private and personal, here are your options
Simplest: add a read-only deploy key
There's a lesser-known option that gives true read-only access to a private personal repo without moving it anywhere: a deploy key. A deploy key is an SSH key tied to a single repository — and when you add one without write access, it can clone and read that one repo and nothing else. It can't push, can't touch your other repositories, and can't change any settings.
The neat part for a code review: the reviewer generates the key pair and keeps the private half. You only ever paste in the public half — a single harmless line of text — so nothing sensitive leaves your side, and you can delete the key in one click when the review's done.
- Ask your reviewer for their public deploy key (a single line that starts with ssh-ed25519 or ssh-rsa).
- In your repository on GitHub, click Settings, then Deploy keys under the Security section.
- Click Add deploy key, give it a clear title like 'Code review (read-only)', and paste the key into the box.
- Leave 'Allow write access' unchecked — that's the part that keeps it read-only — and click Add key.
- When the review's finished, come back to Deploy keys and delete it.
Best for teams: put it in a GitHub organization
Once an organization owns the repository, you can invite the reviewer with the Read role — real, proper read-only. This is the right answer whenever it's a business, a client project, or any professional review: you want the reviewer to inspect the code, not push to it, and you want clean control over that access.
Quick: send a clean code export
If the reviewer doesn't need your Git history, branches, pull requests, or issues, you can simply send them a clean ZIP of the code. The only rule: strip the secrets first. Before you zip it up, remove anything sensitive.
- .env files and any other config that holds secrets
- API keys, secret tokens, and database credentials
- Passwords and SSH keys
- node_modules, build folders, and cache folders (they're huge and unnecessary)
- Any real client or production data
Tidy: make a temporary review repo
You can also create a fresh private repository inside an organization, upload a copy of the code there, and give the reviewer Read access to that. It's handy when you'd rather not move the original yet, want to share only part of the codebase, or want to keep unrelated commit history out of view.
If your repo is in an organization (the easy case)
Organization repositories support proper, fine-grained roles: Read, Triage, Write, Maintain, and Admin. For a code review, the one you want is almost always Read.
The Read role lets a reviewer do everything they need to: view the code, clone the repository, look through branches and commits, inspect how the project is put together, and (depending on your settings) see pull requests and issues.
Just as importantly, Read does not let them push code, merge pull requests, delete branches, change repository settings, manage secrets or users, or transfer or delete the repo. That's exactly the line you want for a reviewer.
How to add a read-only reviewer (organization repo)
- Open the repository on GitHub and click Settings.
- In the left sidebar, find the Access section and click Collaborators & teams.
- Click Add people.
- Search for the reviewer by their GitHub username or email address, and select them.
- Choose the Read role, and send the invitation.
- Ask the reviewer to accept the invite GitHub emails them.
If it's us doing the review and your repo lives in an organization, the account to invite is our reviewer account — thatnerdknows@gmail.com — with the Read role. (You're adding a user, not an organization: GitHub collaborators are always individual accounts, so there's no 'add an organization' option.) For a private personal repo, ask us for a read-only deploy key instead. Either way, set it up before you submit your intake and we can start right away.
Reviewing with a team? Add a team instead
If more than one person needs to review, it's cleaner to use a team than to add each person by hand. Make a team called something like 'code-reviewers', and from then on you manage access by adding or removing people from the team — not by editing the repository every time.
- In your organization, go to Teams and create a new team (or pick an existing one).
- Add your reviewer or reviewers to that team.
- Open the repository, click Settings, then Collaborators & teams.
- Click Add teams, choose your reviewer team, and assign it the Read role.
Moving a personal repo into an organization
If your repo is currently personal and you need true read-only access, transferring it to an organization is usually the move. Your personal account stays intact — you're just changing who owns this one project so you get team-based, role-based access.
Before you transfer, run through a quick checklist:
- You own the repo (or have permission to transfer it), and the destination organization already exists.
- You have the right permissions in that organization.
- Any sensitive data has been removed or rotated.
- Your team knows the repository URL may change.
- You've noted any deployments, webhooks, or integrations to re-check after the move.
- Open the repository, click Settings, and scroll down to the Danger Zone.
- Click Transfer ownership and read GitHub's warnings.
- Enter the repository name to confirm, then enter the destination organization name.
- Confirm the transfer.
- Once it's owned by the organization, open Settings → Collaborators & teams and add your reviewer (or team) with the Read role.
A message you can send your reviewer
When the review's done: remove access
Once the review is wrapped up, take a minute to remove the reviewer's access — good hygiene, and it keeps your access list honest.
- Open the repository and click Settings, then Collaborators & teams.
- Find the reviewer or the reviewer team.
- Remove their access. If it was granted through a team, remove the person from the team or the team from the repo.