How do you archive a GitHub repository, and should you?

Short answer first, then the part that is actually worth your attention.

How to do it

Open the repository. Settings. Scroll to the bottom, to the section labelled danger zone. Choose “Archive this repository”, confirm by typing the name.

Done. It is now read-only for everyone including you, and carries an archived banner.

To reverse it: same page, “Unarchive this repository”.

What archiving preserves

Everything. Code, full commit history, branches, tags, releases, issues, pull requests, stars, watchers. Nothing is removed and nothing is compressed away.

What changes is that the repository becomes read-only. No pushes, no new issues, no new pull requests, no comments. Existing content stays exactly as it was.

Visibility is untouched. Private stays private.

                       archive          delete
                     ───────          ──────
code                   kept             gone
commit history         kept             gone
issues and PRs         kept             gone
reversible             yes              no
still an asset         yes              no

Archiving a branch instead of a whole repository

GitHub has no archive button for branches. The usual approach is to tag the branch so its commits stay reachable, then delete the branch itself:

git tag archive/feature-x feature-x
git push origin archive/feature-x
git push origin --delete feature-x

The branch disappears from the branch list, nothing in its history is lost, and you can recreate it from the tag at any time.

Looking for git archive?

Different thing, same word. git archive is a git command that exports a snapshot of your files at one commit as a zip or tarball:

git archive --format=zip --output=snapshot.zip main
git archive --format=tar.gz --output=release.tar.gz v1.2.0

GitHub’s “Download ZIP” button produces the same kind of file. It is useful for shipping a release. It is not a backup of the repository, because the export contains no history at all: no commits, no messages, no branches. Which matters for the reason below.

Why this matters more than it used to

Deleting a repository used to be a tidying decision with no real downside. It is not any more, and the reason is specific.

Commit history is the large majority of the licensable token volume in a repository, typically something like twenty times the volume of the final source. It is also the part that cannot be reconstructed. You can always rewrite code. You cannot recover the eight years of decisions that produced it.

So deleting a dormant repository is not neutral housekeeping. It permanently destroys the larger half of an asset, to save a line in a list you rarely look at.

Archiving achieves everything deletion was ever actually for. The repository stops appearing in your active work, stops accepting changes, and stops being something you feel vaguely responsible for. And it is reversible.

┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐
│                                                                      │
│  Private, finished, owned by you: $500+ each to AI labs.             │
│                                                                      │
│  [ See what my repos are worth ]                                     │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

The related mistake: squashing history

Same failure mode, more common, and it happens to repositories people intend to keep.

Squashing a branch into a single commit before merging, rewriting history to tidy the log, or starting a fresh repository so the first commit looks clean: each of these discards the record of how the code got to be the way it is.

For day to day engineering these are defensible habits with real arguments behind them. For anything you might license, they are straightforwardly destructive. The failed approach that got reverted is signal. The commit message that says “ok this actually works” is signal. The four attempts at the same bug are the most useful thing in the repository.

If a codebase is dormant, leave its history alone. There is nothing to tidy for and something real to lose. What that history is worth, and why, is in should you squash commits.

A sensible policy for old work

Active. Leave it.

Dormant but you might return. Archive it. Reversible, costs nothing.

Finished and never returning. Archive it. This is the category people delete, and it is the category most likely to be worth something, because finished private projects with years of history are precisely what is scarce.

Genuinely worthless. Scratch repositories, tutorial follow-alongs, a throwaway from an afternoon. Delete freely. Nothing here is an argument for hoarding. The steps, and what deletion cannot undo, are in how to delete a GitHub repository.

Contains real secrets and you are nervous. Archive it. Rotating the exposed credentials is the actual fix, and it is the fix whether you delete the repository or not, since the history may exist in clones and forks regardless. Deleting the repository does not un-leak a key.

The thing to do this week

Go through your account and archive rather than delete. It takes a few minutes per repository, changes nothing about how you work, and keeps open an option that costs you nothing to hold.

Then, if you want to know what the archive amounts to, estimate it.

What to read next

• Can you license private repositories, on what dormant private code is worth
• Is my private code used to train AI, before you delete anything out of anxiety
• What AI labs pay for code, why history dominates the figure