How to export, review, and apply GitHub repo-team access changes in repod

This is the core repod workflow for cleaning up GitHub repo-team access without hand-editing everything in the GitHub UI.

Use it when you need to review current access, edit target permissions in bulk, and apply changes with a visible diff instead of a series of ad hoc clicks.

TL;DR

Problem: GitHub repo-team access cleanup gets slow and risky when you have to inspect and edit permissions one repo at a time.
Who this is for: GitHub org admins, maintainers, and operators handling access cleanup or delegated access operations.
What this helps you fix: bulk review, repo-team access cleanup, and safer apply workflows with a before/after diff.

Problem this solves

In a real GitHub org, the access model usually drifts in small pieces: one direct grant for a release, one temporary team mapping for a contractor, one repo moved to a new squad, then a few sensitive repos nobody wants to touch before a deadline. The result is not one obvious broken setting. It is a live repo-team graph that is hard to review, hard to delegate, and awkward to clean up safely.

This workflow turns that mess into a controlled change set: export the current access state, make the intended target state explicit, preview the delta, and apply only after the diff is clear.

repod workbook workflow for reviewing GitHub repo-team access in a spreadsheet — repod gives operators a spreadsheet-shaped review surface for repo-team access, then brings the edited target state back for validation and preview.

Before repod

Repo access is reviewed one GitHub screen at a time.
Direct grants and old team mappings are easy to miss.
Cleanup is hard to delegate because org admin is too broad.
There is no single before/after diff for the whole change set.

With repod

Current repo-team access is exported into one workbook.
Target access can be edited in bulk before anything changes.
Operators can preview the proposed diff before apply.
The apply step is deliberate, visible, and easier to audit.

1. Prerequisites

Your GitHub org is connected to repod.
Your PAT has the right scopes for the workflow you want to run.
You have the repod role needed to run assignment workflows for the account.

If PAT setup is not complete yet, start with GitHub fine-grained PAT guidance for repod.

2. Export the current state

Go to the access planning workflow and export the current repo-team access state. This gives you a spreadsheet view of how repositories and teams are currently mapped.

The export is useful for two reasons:

It gives you a review surface that is easier to scan than clicking through individual repos.
It gives you a controlled way to edit target access before anything is applied back to GitHub.

3. Review and edit target permissions

In the spreadsheet, review the current assignments and set the target state you actually want. This is the right time to:

remove stale team access
standardize permission levels
move repositories under the right teams
prepare access cleanup before an audit or org restructure

Keep this workflow focused on repo-team access. If your structure itself is wrong, fix the team model as well rather than encoding long-term exceptions into the spreadsheet.

4. Import the workbook

Import the edited workbook back into repod. The import step is not the apply step. It is the point where repod validates the edited target state and prepares the change set for review.

5. Review the diff before apply

Review the diff carefully. The point of the workflow is that access cleanup should be reviewable and auditable before it changes GitHub.

Check which team-repo links will be added.
Check which team-repo links will be removed.
Check which permission levels will change.
Pause if the change set includes more access than expected or removes something safety-critical.

6. Apply changes

Once the diff looks right, apply the changes. repod will enact the reviewed repo-team permission changes against GitHub using the stored PAT.

This is the point where repod is operationally different from “just use the GitHub UI”: you have one review surface, one diff, and one apply path for a whole change set.

repod diff preview before applying GitHub repo-team access changes — The important control is the preview: GitHub writes happen after the proposed repo-team changes have been reviewed.

7. Use cases where this workflow is strongest

cleaning up stale team access after org changes
standardizing permissions ahead of an audit
moving repositories under clearer team ownership
delegating day-to-day repo-team access work without broad GitHub org admin

FAQ

Does the export apply changes to GitHub?

No. Exporting and importing are review steps. GitHub is not changed until an authorized user applies a validated preview.

Why use a workbook instead of clicking through GitHub?

A workbook makes repo-team access easier to scan, compare, and edit in bulk. It is useful when the job is operational cleanup across many repositories, not one isolated permission change.

What should I fix before using this workflow?

If the team structure itself is unclear, read the GitHub Teams guide first. The workbook is strongest when you already know the target operating model.

Try the workflow on a real org

Start with the free audit to see whether stale mappings, direct access, or weak team coverage are worth cleaning up.

Run Free GitHub Access Audit