The earlier Forking and Pull Requests lesson covered contributing without direct access — the standard way to work with strangers on a public project. A collaborator is different: someone given direct write access to push straight to the repository itself.
From a repository's Settings → Collaborators and teams → "Add people," searching by their GitHub username or email. They receive an invitation, which they need to accept before access takes effect.
| Level | Can do |
|---|---|
| Read | View and clone the repository, comment on issues/PRs |
| Triage | Read, plus manage issues and PRs without write access to code |
| Write | Read/Triage, plus push directly to non-protected branches, and merge PRs |
| Maintain | Write, plus manage some repository settings, without full admin access |
| Admin | Full control, including deleting the repository or changing who has access |
| Direct collaborator access | Fork and pull request |
|---|---|
| A small, trusted team working on the same private or public project | An open-source project accepting contributions from anyone |
| Faster — push straight to a branch, no fork needed | Slower per-contribution, but keeps the original repository fully controlled |
| Requires trusting someone with real write access | The maintainer reviews every change before it goes in, from anyone |
Even with collaborators added, a branch protection rule can require every change — even from a collaborator with Write access — to go through a pull request and pass checks before merging into main, rather than allowing a direct push.
A common real-world setup
Requiring pull requests even from trusted collaborators, via a branch protection rule, is standard practice on real projects — it keeps a review step and a clean history even when direct push access exists.