How to Add Collaborators on GitHub

You’ve built something worth sharing. Now it’s time to bring people in.

Whether you’re working with a remote team, onboarding a contractor, or open-sourcing a project — knowing how to add collaborators on GitHub correctly is one of those foundational skills that saves you hours of frustrating back-and-forth.

Over 100 million developers use GitHub today. And the majority of them aren’t working alone. According to GitHub’s own data, more than 90% of the Fortune 100 rely on GitHub for collaborative development. That’s not a coincidence — it’s because shared repositories and structured access are what make modern software teams move fast without breaking things.

This guide walks you through every method to add collaborators, manage their permissions, and avoid the most common mistakes teams make when opening up their repos.

What Are GitHub Collaborators?

A GitHub collaborator is anyone you grant direct access to your repository — outside of your own account or organization.

Collaborators can push code, create branches, open pull requests, and interact with issues depending on the access level you give them. By default, collaborators on a private repository have no access until you explicitly invite them.

There are two distinct contexts here:

• Personal repositories — repositories owned by an individual GitHub account
• Organization repositories — repositories owned by a GitHub organization with team-based access control

The process for adding collaborators differs slightly between the two, and getting it wrong can either lock someone out or accidentally give them more access than intended. We’ll cover both in detail.

Why Getting Collaborator Access Right Matters

Here’s a number that should make you pause: 68% of data breaches involve a human element, according to Verizon’s 2023 Data Breach Investigations Report. Misconfigured access permissions are one of the most common entry points.

On GitHub specifically, the risk is real. Accidentally granting write access to an outside contractor on a production repository isn’t a hypothetical — it happens regularly in teams that move fast without a clear access management process.

On the flip side, being too restrictive kills momentum. Studies show that developers lose an average of 4.5 hours per week navigating unnecessary access friction. That’s half a workday, every week, gone.

Getting collaborator access right is about hitting that middle ground: open enough to move fast, locked down enough to stay safe.

How to Add Collaborators to a Personal Repository on GitHub

This is the most straightforward path — ideal for solo developers, freelancers, and small project teams.

Step 1 — Go to Your Repository Settings

Navigate to the repository you want to share. Click the Settings tab at the top of the repo page (you need to be the repo owner or have admin access to see this).

Step 2 — Open the Collaborators Section

In the left sidebar under Access, click Collaborators. GitHub may prompt you to re-enter your password or confirm via two-factor authentication before proceeding.

Step 3 — Send the Invitation

Click Add people. You can search by:

• GitHub username
• Full name
• Email address (if associated with a GitHub account)

Select the correct person from the dropdown and click Add [username] to this repository.

Step 4 — Collaborator Accepts the Invite

GitHub sends an email invitation to the person. They need to accept it before they gain access. Invitations expire after 7 days if not accepted — something many teams forget when onboarding someone who isn’t checking their email regularly.

You can also send them the direct invite link from the Collaborators page as a faster alternative.

How to Add Collaborators to an Organization Repository

Organizations work differently. Instead of inviting individuals directly to each repository, the recommended approach is to use Teams — which gives you far more control at scale.

Using Teams (Recommended for Organizations)

Step 1 — Go to your organization’s main page and click the Teams tab.

Step 2 — Click New team or select an existing team that matches the access level needed.

Step 3 — Add members to the team. You can invite by GitHub username or email.

Step 4 — Grant the team access to specific repositories by going to the team’s Repositories tab and clicking Add repository.

Step 5 — Set the permission level for that team on that repository (Read, Triage, Write, Maintain, or Admin).

Adding an Outside Collaborator Directly to an Org Repo

If you need to add someone who isn’t an organization member (e.g., a contractor or external partner), you can add them as an outside collaborator directly:

Go to Settings → Collaborators and teams inside the specific repository, then use the Add people button under the Manage access section.

Keep in mind: organization owners can restrict this capability. If you don’t see the option, contact your org admin.

GitHub Permission Levels Explained

This is where most teams get tripped up. GitHub offers five repository permission levels, and each one is meaningfully different:

A few practical rules of thumb:

• External contractors should almost never have Admin access
• Most contributors only need Write access
• Code reviewers who don’t push code can work perfectly well with Triage
• Read is appropriate for stakeholders who need visibility but shouldn’t touch code

According to a GitHub survey, teams that enforce role-based access control report 40% fewer security incidents compared to those using blanket access policies.

Managing and Revoking Collaborator Access

Adding collaborators is only half the process. The other half — the part most teams neglect — is removing access when it’s no longer needed.

How to Remove a Collaborator

Go to Settings → Collaborators in a personal repo, or Settings → Collaborators and teams in an org repo. Find the person’s name and click Remove.

When you remove a collaborator:

• They immediately lose push access
• Any forks they created of a private repo remain in their account
• Their past commits remain attributed to them in the history

Set a Review Schedule

The industry standard for access reviews is quarterly — but for fast-moving teams, monthly is better. Research from the Cloud Security Alliance found that 58% of organizations have former employees or contractors with active repository access they’ve forgotten to revoke.

Build a simple process: every 30-90 days, export your collaborator list and cross-reference it with your active roster.

Best Practices for GitHub Collaboration

Here’s what high-performing teams consistently do differently:

Use branch protection rules. Even trusted collaborators with Write access shouldn’t be pushing directly to main or production. Set required pull request reviews, status checks, and dismiss stale reviews in your branch protection settings.

Enable two-factor authentication (2FA) requirements. For organization repositories, you can require all members and collaborators to have 2FA enabled. Only 36% of GitHub users had 2FA enabled before GitHub made it mandatory for code contributors in 2023 — and that gap was directly responsible for thousands of account compromises.

Document your access policy. Even a simple README in a private team-docs repo goes a long way. Specify who gets what level, who approves changes, and how to request access.

Use Deploy Keys for automated systems. If a CI/CD tool or bot needs repo access, give it a deploy key — not a personal access token attached to a real person’s account. This way, when someone leaves, your pipelines don’t break.

Audit your outside collaborators list. Inside an organization, go to Settings → People → Outside collaborators to see everyone who has repo access but isn’t an org member. This list tends to grow quietly and never shrink without intentional effort.

Common Issues When Adding GitHub Collaborators

“I can’t find the Collaborators option in Settings.” This usually means you don’t have admin access to the repository, or — for organization repos — the org has restricted outside collaborator invitations. Contact the repo owner or organization admin.

“The invitation expired before they accepted it.” GitHub invites expire after 7 days. Go back to Settings → Collaborators and resend the invite. Share the direct invite link with them via Slack or email for faster acceptance.

“Collaborator accepted but still can’t push.” Check if branch protection rules are blocking their pushes. Even with Write access, protected branches may require pull request reviews. Also verify they’re pushing to the correct branch.

“I accidentally gave someone Admin access.” Go to Settings → Collaborators, find their name, and change their role immediately using the dropdown. Don’t wait — Admin access means they can delete the repository.

“Can I add a collaborator without them having a GitHub account?” No. GitHub requires the collaborator to have an account. If they don’t have one, they’ll need to create a free account first.

Conclusion

Adding collaborators on GitHub isn’t complicated — but doing it right requires intentionality.

Use the direct collaborator invite for personal repositories and small external partnerships. Use Teams for organization repositories at any real scale. Set the minimum permission level that gets the job done, enforce branch protection on critical branches, and build a habit of reviewing and revoking access on a regular cadence.

The teams that move fastest on GitHub aren’t the ones with the most permissive access policies. They’re the ones with the clearest ones.

Start with the right foundation, and every contributor you add makes the project stronger — instead of introducing risk.