Quick Facts Table
| Topic | Details |
| Platform | GitHub (owned by Microsoft) |
| Feature Name | Collaborators / Manage Access |
| Where to Find It | Repo → Settings → Collaborators |
| Who Can Add People | Repo owner or Admin-level user |
| Invite Expires In | 7 days |
| Works for Private Repos? | Yes (may use a paid license seat) |
| Permission Levels | Read, Triage, Write, Maintain, Admin |
| Works Without GitHub Account? | No — invitee must have or create one |
| Organization Repos | Extra steps via “People” tab |
| Best for Small Teams | Direct Collaborator method |
| Best for Open Source | Fork + Pull Request model |
Why This Matters More Than You Think
Picture this. You’ve been building something for weeks. A side project. A school assignment. Maybe a tool for work. Another person wants to assist immediately.
That’s a great moment. Collaboration is how good code becomes great code.
But if you’ve never done this before, GitHub’s interface can feel a little cold. A lot of menus. A few confusing terms. And suddenly you’re wondering — wait, do I give them Write access or Admin? What even is Triage?
Don’t worry. By the end of this article, you’ll know exactly what to do and why.
See also “How to See Deleted Instagram Messages: Everything You Need to Know (2026)“
Before You Start: Two Things You Need
There are just two things required before you add anyone.
First, you need to be the repository owner — or at least have Admin-level access. If you can’t see the “Settings” tab inside your repo, you don’t have that access. Someone else does, and they’ll need to make the invite.
Second, the person you’re adding needs a GitHub account. If they don’t have one yet, point them to github.com — it takes two minutes to sign up for free.
Got both? Good. Let’s go.
Method 1: Adding a Collaborator to a Personal Repository (Most Common)
This is the method most people need. It works for any repo you personally own.
Step-by-Step
Step 1: Log into GitHub and open the repository you want to share.
Step 2: Select the top-level Settings tab. It’s usually the last tab in the row. If you don’t see it, check if there’s a dropdown menu hiding it.
Step 3: Look at the left sidebar. Find the section called Access. Click on Collaborators.
Step 4: You might be asked to confirm your password or use two-factor authentication. GitHub just wants to make sure it’s really you.
Step 5: Click the green Add people button.
Step 6: A search box pops up. Type the person’s GitHub username or their email address. GitHub will suggest matching accounts as you type.
Step 7: Click their name when it appears.
Step 8: Choose a permission level (more on this shortly). Then click Add [name] to [repository].
Step 9: GitHub sends them an invitation by email. They also get a notification inside GitHub at github.com/notifications.
Step 10: Once they click Accept invitation, they have access. You can refresh the Collaborators page to confirm they appear in the list.
That’s it. Really.
Understanding Permission Levels (This Part Is Important)
Here’s where a lot of people make mistakes. They just give everyone “Admin” and move on. That creates real problems later.
GitHub offers five permission levels. Think of them like keys. You give someone the key that opens exactly the doors they need — and no more.
Read
This is the most basic level. The person can view the code, clone it, and leave comments on issues. They cannot change anything.
Use this for people who just need to see your work. Clients reviewing a project. Teachers checking homework. Anyone who needs eyes-only access.
Triage
A step above Read. With Triage, someone can manage issues and pull requests — labeling them, closing them, reopening them — but they still can’t push any code changes.
This suits community managers, QA testers reviewing bug reports, or anyone helping keep the project organized without writing code.
Write
This is the workhorse permission. Write lets someone push code, create branches, and merge pull requests. Most developers on a team get Write access.
If someone is actively building features or fixing bugs with you, Write is the right choice.
Maintain
This sits between Write and Admin. A Maintain user can do almost everything a repo manager needs — editing descriptions, managing issues, publishing releases — but they can’t delete the repository or touch sensitive security settings.
Great for a senior developer or project lead who helps run the project day-to-day but doesn’t need the nuclear option.
Admin
Full control. An Admin can change settings, manage everyone’s access, rename the repository, and even delete it entirely.
Only give Admin to people you fully trust. Usually that means co-founders, lead engineers, or other project owners.
Golden rule: Give people the lowest level of access that still lets them do their job. This is called the principle of least privilege, and it protects your project.
What Happens After You Send the Invite?
The person gets an email from GitHub. The subject line looks like “[yourusername] has invited you to collaborate.”
Inside the email is a button that says Accept invitation.
They need to click that within 7 days. After that, the invitation expires. If they miss the window, you can just send it again — no big deal.
Once they accept, they show up as an active collaborator on your Collaborators page. You can see their name and their permission level right there.
And if they never seem to get the email? Tell them to check spam. It’s almost always in spam the first time.
Method 2: Adding Someone to an Organization Repository
If your repo belongs to a GitHub Organization — a company account, a school team, an open-source project group — the steps are a little different.
Organizations have their own member system. Adding someone as an organization member is broader than adding them to one specific repo.
Adding a New Member to the Organization
Step 1: Go to your organization page on GitHub (github.com/your-org-name).
Step 2: Click the People tab.
Step 3: Click Invite member.
Step 4: Type the person’s GitHub username or email. Click their name.
Step 5: Choose a role. Member is the standard. The owner gives full admin control over the entire organization — use this sparingly.
Step 6: Optionally, add them to one or more Teams (covered next). Click Send invitation.
Adding Someone Only to a Specific Repo in an Organization
Sometimes you don’t want to make someone a full org member. A freelancer, for example. Or someone helping with one project temporarily. These people are called Outside Collaborators.
To add an outside collaborator:
Step 1: Go to the specific repository inside your organization.
Step 2: Click Settings → Collaborators & Teams.
Step 3: Click Add people, search for the person, and assign a permission level.
Step 4: Send the invitation.
They get access only to that one repository. They don’t become an org member. They can’t see other repos or org-wide settings.
One thing to know: adding an outside collaborator to a private repository may use one of your paid license seats, depending on your GitHub plan.
Using GitHub Teams (The Smart Way for Bigger Groups)
If you’re managing more than two or three people, manually setting permissions for each person in each repo gets exhausting fast.
Teams solve this beautifully.
A Team is a named group inside your organization. You give the Team a permission level for one or more repositories. Then you just add people to the Team — and they automatically inherit the right access.
Why This Is Better
Imagine you have a “Frontend Developers” team with Write access to three repos. When you hire a new frontend developer, you add them to that one team. Done. They instantly have the right access to all three repos.
No need to touch individual repo settings. No risk of forgetting a repo. No permissions audit headache six months later.
How to Create and Use Teams
Step 1: Go to your organization page.
Step 2: Click the Teams tab.
Step 3: Click New team. Give it a clear name like “Backend Engineers” or “Design Reviewers.”
Step 4: Add members to the team.
Step 5: Next, navigate to Settings → Collaborators & Teams → Add teams in each pertinent repository. Choose your team and set its permission level.
Every team member gets that access automatically.
The Fork + Pull Request Model (For Open Source Projects)
Here’s something important. If your project is public and open source, you probably don’t want to add random contributors as collaborators at all.
Instead, the standard approach is the fork and pull request workflow.
Here’s how it works from a contributor’s perspective. They go to your public repo and click Fork. This creates their own personal copy of your code. They make changes in their fork. Then they submit a Pull Request asking you to merge their changes into your original repo.
You review the pull request. You can comment on specific lines, request changes, or approve it. Only after you approve does the code enter your repo.
This means your main codebase stays safe. Contributors never touch your repo directly. You’re always in control of what gets merged.
Use the collaborator method for trusted teammates who work with you regularly.
Use the fork + PR model for public contributors or anyone you haven’t personally verified.
Security Tips: Don’t Skip These
Adding people to your repo sounds simple. And mostly it is. But a few small habits make a big difference in keeping your code safe.
Never give out Admin access casually. Even to people you trust. Admin can delete everything. If someone only needs to write code, Write access is enough.
Require 2FA for your collaborators. Two-factor authentication means a stolen password alone can’t break in. In your organization settings, you can make 2FA mandatory for all members.
Use branch protection rules. Even if someone has Write access, you can stop them from pushing directly to your main branch. Require that all changes come through a pull request with at least one review. This catches mistakes before they cause damage.
Review your collaborators list regularly. Developers change jobs. Projects end. Old teammates sometimes keep access they no longer need. Once every few months, open that Collaborators page and remove anyone who shouldn’t still be there.
Be careful with private repos. Adding someone to a public repo is low risk — the code was already visible. Adding someone to a private repo exposes code that was previously secret. Think before you click.
What to Do If You Can’t See the Settings Tab
This trips people up a lot.
If the Settings tab is missing, it almost always means one of two things.
Either you don’t own that repository and no one has given you Admin-level access. Or the Settings tab is hidden in a dropdown menu — look for a “…” or a collapsed menu at the right end of the repo tabs.
If you’re trying to add a collaborator to someone else’s repo, you need to ask the owner to either make you an Admin or send the invitation themselves.
What If the Person Never Gets Their Invite?
First, tell them to check spam. GitHub invitation emails get filtered a lot.
Second, make sure you used the right email — the one actually linked to their GitHub account, not just any email they have.
Third, if the invite expired (after 7 days), go back to the Collaborators page and resend it. There’s an option right there to cancel or resend pending invitations.
Removing a Collaborator
Things change. Someone leaves the team. A project wraps up. You need to remove access.
It’s easy. Go to Settings → Collaborators. Find their name. Click the Remove button.
They lose access immediately. Their commits and past contributions stay in the repo history — that doesn’t change. But they can no longer push, pull, or view private content.
Using the GitHub CLI or API (For Developers)
If you’re comfortable in a terminal, GitHub offers a command-line way to do this.
Using the GitHub CLI:
gh api –method PUT /repos/OWNER/REPO/collaborators/USERNAME -f permission=’write’
Replace OWNER, REPO, and USERNAME with the real values. Replace ‘write’ with whatever permission level you want.
This is especially useful for onboarding scripts — when you regularly add new team members and want to automate the whole process.
Final Words
Adding someone to a GitHub repository takes about two minutes. But doing it thoughtfully — picking the right permission, knowing when to use Teams, understanding the difference between a collaborator and an outside contributor — that’s what separates clean projects from chaotic ones.
Start simple. Add your collaborator. Give them Write access if they’re writing code. Don’t hand out Admin like candy. And check that list periodically so old access doesn’t linger.
The best codebases are built by people who work together with trust and clear boundaries. Permission levels aren’t about distrust. They’re about protecting the work everyone is pouring their energy into.
Now go build something great with your team.
FAQs
1. Does adding a collaborator to a private GitHub repository cost money?
Adding collaborators to private repos on a paid plan (like GitHub Team or Enterprise) uses a license seat per person. On GitHub Free, private repos are limited to three collaborators. Public repos have no cost limit.
2. Can I add someone who doesn’t have a GitHub account?
You can use their email address to send them an invitation. GitHub will prompt them to create an account when they click the invitation link. They must create an account before they can accept it.
3. How long does the invitation stay active?
GitHub invitations expire after 7 days. If the person doesn’t accept it within that window, you’ll need to resend it. You can do this from the Collaborators page.
4. What’s the difference between a collaborator and an organization member?
A collaborator has access only to specific repositories. An organization member is part of the entire org and can be added to Teams that span multiple repos. For freelancers or external contributors, the collaborator route is better.
5. What happens to the code if I remove a collaborator?
Nothing. Their past commits stay in history. Removing them just ends their ability to push new changes, open pull requests (if private), or view private repo content going forward.
6. Can a collaborator delete my repository?
Only if you give them Admin access. Admin is the only level that can delete a repository. Write, Triage, Read, and Maintain cannot.
7. How many collaborators can I have?
On a public repository, there is no limit. In a private repository, it depends on your plan. GitHub Free allows up to 3 collaborators on private repos. Paid plans allow unlimited collaborators.
8. I can’t see the Settings tab. What’s wrong?
You likely don’t have Admin access to that repository. Only the owner or an Admin-level collaborator can access Settings. Ask the repo owner to either grant you Admin or add the person on your behalf.
9. Can I add a collaborator using just their email address instead of their username?
Yes. In the “Add people” search box, you can type either their GitHub username or the email address connected to their account. If they don’t have an account, they’ll be prompted to create one when they receive the invite.
10. What’s the difference between Write and Admin?
Write lets someone push code and merge pull requests. Admin lets someone change repository settings, manage other collaborators, and delete the entire repository. Give Write to developers and Admin only to trusted project leads.
11. Can I change a collaborator’s permission level after adding them?
Yes. Go to Settings → Collaborators, find their name, and adjust their role from the dropdown. Changes take effect immediately.
12. What is an Outside Collaborator in GitHub Organizations?
An outside collaborator is someone who isn’t an official org member but has been given access to one or more specific repos. It’s the right choice for contractors, freelancers, or temporary contributors who shouldn’t have full org membership.
13. What is the fork and pull request model and when should I use it?
Forking means a contributor makes their own copy of your repo, makes changes there, and then asks you to merge those changes via a pull request. Use this model for public/open-source projects where you don’t know or fully trust every contributor. Use direct collaborators for your trusted core team.
14. How do I add multiple people to multiple repos efficiently?
Create GitHub Teams inside an organization. Add people to a team and grant that team access to the relevant repos. This saves time and keeps permissions consistent across your whole project.
15. Can someone add themselves to my repository?
No. Only the repository owner or an Admin can send invitations. No one can add themselves without an explicit invitation from you. Your code is safe unless you choose to share it.
Keep creating, innovating, and inspiring with Content Ideators every day.
