Skip to main content
In this lesson you’ll learn how to manage collaborators and repository access within a GitHub organization. We cover where to review pending invitations, how users accept invites, transferring repositories into an organization, and assigning repository roles (Read, Triage, Write, Maintain, Admin).

​
Review pending invitations and members

From your organization page, open the People tab to inspect pending invitations and current members. This view shows outstanding invites and active organization members.
This image shows a GitHub organization’s "People" tab, specifically the "Invitations" section, listing two pending invitations for members "Siddharth" and "Alice" with invitation details.

​
How invitations are accepted

Invited users will receive an invitation they can accept or decline from their GitHub account. The invitation may include metadata (for example, whether two-factor authentication is enabled and the invitation source). GitHub also surfaces controls to manage or limit future invitations within the invitation page and the user’s account settings.
Invitations show security metadata such as two-factor authentication status. If your organization requires 2FA, an invitee must enable it before joining. See GitHub’s 2FA documentation for setup steps.
For example, Alice receives an invitation to join the PixelCraft organization and can accept or decline from her account.
The image shows an invitation to join the "Pixelcraft-Studio-kk" organization on GitHub, with options to accept or decline the invitation.
After Alice accepts the invitation, refresh the People view in the organization to confirm she appears as a member and to view any remaining pending invitations (for example, an invitation still pending for Siddharth).
The image shows a GitHub page for an organization named "Pixelcraft-Studio-kk," inviting users to create a new repository. It features an icon and some user avatars.

​
Creating or transferring repositories to an organization

If your organization has no repositories yet, you can either create a new repository inside the organization or transfer repositories from a personal account.
  • Create a new repo under the organization.
  • Transfer one or more repositories from a personal account into the organization. Transfers preserve the commit history, issues, pull requests, and metadata.
The image shows a GitHub settings page for organizations, displaying options for creating or moving work to an organization, with various settings like "Organizations" highlighted.
When moving work, GitHub lists repositories and projects you can select. Choose the items to transfer and confirm; transfers may take a few minutes depending on repository size.
The image shows a GitHub interface for moving work into an organization, listing repositories like "block-buster," "bb-2," and "flux2," with options to select them.
Repository transfers retain issues, pull requests, and commit history. If you plan to consolidate many repos, consider communicating with contributors about timing and access changes.

​
Managing repository access and collaborator roles

Inside each repository, go to Settings → Collaborators & teams (or Manage access) to add users directly or grant access through organization teams. Direct access assignments let you select a role for each user, typically: Read, Triage, Write, Maintain, or Admin. Enterprise accounts can also create custom roles. Below is an example repository page showing users who have access to the “block-buster” repository. Users with Write access can edit files directly in the GitHub web UI.
The image shows a GitHub repository page for "Pixelcraft-Studio-kk," featuring a public template repository named "block-buster" for a JavaScript game. The user's profile dropdown is open, revealing options like status and repository management.
Example: a collaborator with Write access can edit index.html directly in the repository. Below is a sample HTML file demonstrating an editable front-end file:
When a user has Read access, they can clone and view the repository and comment on issues and pull requests, but they cannot push changes. Attempting to edit a file in the web UI will prompt a Read user to fork the repository and create a branch in the fork. The normal contribution workflow for Read users becomes: fork → make changes → open a pull request against the organization repository.

​
Quick reference: roles and capabilities

The image shows a GitHub repository settings page for managing access, where different users are listed with specified roles and permissions. There is an emphasis on role selection, with options to read, triage, write, or add custom roles via GitHub Enterprise.
Grant Admin or Maintain roles only to trusted users. Admin access allows repository settings changes, including collaborator management and potentially destructive actions (like deletion).

​
Best practices

  • Assign the least privilege required: prefer Read or Triage where possible and escalate to Write/Maintain only when needed.
  • Use teams to manage permissions at scale — assign access to teams instead of individual users when multiple repos or many users are involved.
  • Require 2FA and consider organizational policies to protect sensitive repositories.
  • Communicate transfers and permission changes with contributors to avoid confusion.

Watch Video