How to Add a Collaborator in GitHub: A Complete Guide

GitHub makes collaborative development straightforward once you know where to look. Whether you're working on a personal project with a friend or coordinating across a small team, adding a collaborator gives another GitHub user direct push access to your repository. Here's exactly how it works — and what to consider before you do it.

What "Collaborator" Actually Means on GitHub

Before diving into the steps, it's worth understanding what collaborator access entails. On GitHub, a collaborator is someone you've explicitly invited to contribute to a specific repository. Once accepted, they can:

• Clone and push changes directly to the repository
• Create and merge branches (depending on branch protection rules)
• Open, edit, and close issues and pull requests
• Manage certain repository settings (on private repos)

This is different from simply forking a repo or being a member of a GitHub organization. Collaborator access is granted per-repository and is the standard method for personal accounts working with others on shared projects.

How to Add a Collaborator to a GitHub Repository 🛠️

The process is handled entirely through GitHub's repository settings. Here are the steps:

Step 1: Navigate to Your Repository

Log into your GitHub account and open the repository you want to share. You must be the repository owner or have admin-level access to manage collaborators.

Step 2: Open Repository Settings

Click the Settings tab at the top of the repository page. This tab is only visible to users with admin or owner permissions. If you don't see it, you likely don't have the right access level.

Step 3: Go to the Collaborators Section

In the left sidebar, find and click Collaborators (sometimes listed under Access → Collaborators depending on your repository type). GitHub may prompt you to confirm your identity with your password or two-factor authentication at this point.

Step 4: Send the Invitation

Click Add people, then type the collaborator's GitHub username, full name, or email address into the search field. Select the correct user from the results and click Add [username] to this repository.

Step 5: The Collaborator Accepts

GitHub sends the invited user an email notification and an in-app notification. The invitation appears in their GitHub notifications and also at github.com/notifications. They must accept the invitation before gaining access. Invitations expire after 7 days if not accepted.

Collaborator Access on Public vs. Private Repositories

The collaborator workflow is the same regardless of repo visibility, but what changes is the default level of access:

For private repositories, adding a collaborator is necessary just to let someone view the code. For public repositories, anyone can already read and fork — but only collaborators can push directly.

Permission Levels and Branch Protection

When you add a collaborator to a personal repository, GitHub doesn't offer granular role options the way GitHub Organizations do. Personal repo collaborators get a standard level of write access by default.

However, you can still control what they can actually change by setting up branch protection rules:

• Require pull request reviews before merging to main
• Restrict who can push to specific branches
• Require status checks to pass before merging

These rules sit on top of collaborator access and are an important consideration for projects where code quality or stability matters.

GitHub Organizations vs. Personal Repos

If you're managing a larger team or multiple repositories, the collaborator model on personal accounts has some limitations worth knowing:

• There's no role differentiation (no "read-only" option — everyone gets write access)
• Managing access across many repositories becomes manual and repetitive
• You can't create teams or nested permission structures

GitHub Organizations solve these problems by introducing Teams, role-based permissions (read, triage, write, maintain, admin), and centralized access management. If your use case involves multiple contributors across multiple repositories over the long term, the organizational structure handles that complexity much more cleanly.

Variables That Affect Your Setup

The right approach to adding collaborators depends on several factors that vary from one project to the next:

• Number of contributors — a two-person side project behaves very differently from a ten-person open source repository
• Repository visibility — private repos require collaborator access for any external viewing; public repos only need it for write access
• Security requirements — whether your project involves sensitive code or data affects how carefully you should manage branch protections alongside collaborator access
• Contributor familiarity with Git — a new collaborator who isn't comfortable with branching workflows may benefit from branch protection rules that add a review step before merging
• Account type — free GitHub accounts have full collaborator features on public repos; private repo collaborator limits have historically varied by plan 🔍

What Happens When You Remove a Collaborator

Removing a collaborator revokes their push access immediately. They won't receive a notification, but they will lose write permissions the moment you remove them from the settings page. Any commits they've already made remain in the repository history — removing access doesn't remove their contributions.

For private repositories, removal also takes away their ability to view the repository entirely, which matters if you're working with contractors or temporary contributors.

The mechanics of adding a collaborator are simple and consistent. What varies considerably is how much that access should be shaped by branch rules, whether a personal repo structure even fits your team size, and how you want to handle things like code review, merge authority, and eventual offboarding. Those answers live in your specific project setup — not in the settings menu itself. 🔐