GitHub repository roles: choose access for a contractor or reviewer
Choose GitHub repository roles for reviewers and contractors. Check inherited organisation access, release ownership and deploy keys.
In this guide
Repository access should follow a concrete task
GitHub’s organisation repository roles progress from Read and Triage through Write, Maintain and Admin. They serve different responsibilities, from discussion and issue management to pushing code and administering sensitive settings.
Begin with what the person must deliver. A technical reviewer who comments on a proposal and a contractor who pushes a branch need different capabilities. Admin is not a prerequisite merely because somebody is experienced or because the work is urgent.
Review the whole access path
GitHub’s organisation-role documentation describes roles beyond a single repository, including all-repository roles. Check organisation membership, team membership and inherited access as well as the role displayed on the target repository.
For an illustrative contractor engagement, write the intended boundary as “work on this repository for this task”. Then ask the organisation owner to check whether other membership or base permissions grant a broader view. The desired scope and the actual effective access must agree.
Give review and release separate owners
Imagine a fictional agency implementing a small integration. The contractor prepares a change; an internal maintainer reviews it; the release owner approves production deployment. Record those responsibilities before granting access. Being able to propose code does not need to mean independently changing production settings.
Include the review process, required checks and who can approve the final release. Repository permissions and branch rules are related controls, but the human responsibility should remain understandable even to somebody who does not remember every product setting.
Use a short access-and-handover record
| Work | Access requirement to assess | Handover question |
|---|---|---|
| Review a technical proposal | Read and discussion capability | Where are decisions recorded? |
| Manage incoming issues | Issue and pull-request triage | Who owns unresolved work? |
| Implement a change | Required branch contribution route | Who reviews and releases it? |
| Maintain repository settings | Specific administrative responsibility | Is broad Admin actually required? |
The entries are requirements to review, not permissions granted by this article. Match the actual organisation plan and configuration. Test the required contribution route on harmless work before sharing a production task.
Offboarding includes keys and connected services
GitHub warns that a deploy key can retain repository access independently of the person who added it. At handover, inventory relevant keys, applications, automation identities and external deployment connections with their owners. Removing one human account does not explain every remaining machine credential.
Do not copy private keys into a handover document. Retain identifiers, approved owners and a controlled rotation or removal plan instead. Use the GitHub profile and maintained-change checklist to keep the delivered code, review and operating responsibility connected.
Frequently asked questions
Does a GitHub code reviewer always need Admin access?
No. Choose a suitable role with the capabilities required for the review; administrative control is a separate responsibility.
Is the role on one GitHub repository the whole access picture?
Not necessarily. Review organisation roles, team membership, base permissions and other access paths as well.
Does removing a contractor automatically remove every deploy key?
Do not assume so. GitHub warns that deploy-key access can persist independently of the person who created it. Review relevant machine access separately.
Put the guide into practice
Explore developer tools tools, then compare your shortlist.
Explore the category →