skip to content

In GitHub, what does archiving a repository do, and how does it differ from transferring it?

level: middleimportance: nice to knowfreq 28%

answer

  1. One freezes, one relocates, one destroys
  2. Read access is unaffected by the freeze
  3. The frozen state can be undone
  4. Old links keep resolving after a move
  5. Grants live in the old organization

basics

~20 s

Archiving makes a GitHub repository read-only — no pushes, no new issues or pull requests, no setting changes — while leaving it visible, and it can be undone. Transferring moves the repository to another account or organization and redirects the old URL.

solid answer

~50 s

**Archiving** freezes a repository: pushes are refused, issues and pull requests cannot be opened or edited, labels and settings are locked, and automation such as Dependabot updates stops. The content stays visible to whoever its visibility allows, and an admin can unarchive it later. It is the honest way to retire a project without deleting history or freeing up its name. **Transferring** changes ownership. The repository moves to another user or organization, taking its issues, pull requests, wiki, stars and watchers with it, and GitHub sets up redirects from the old location for both web and Git traffic. You need admin on the source and the right to create repositories in the target. Access does not survive intact: team grants belonged to the old organization, so the new owner must re-establish who can read and write. Deleting, by contrast, is irreversible and releases the name.

code

json · 3 lines
json
{
  "archived": true
}

go deeper

for a junior

Know the one-line difference: archiving makes a repository read-only but still visible, transferring moves it to a new owner, and deleting removes it for good.

for a middle

Explain what specifically freezes under archiving — pushes, issues, settings, dependency automation — and what a transfer carries with it versus what has to be rebuilt on the other side.

for a senior

Show that you plan the transfer: re-grant access immediately because team grants do not travel, watch for a permissive base permission in the destination, and update remotes rather than relying on redirects.

for a principal

Own the retirement policy: which organization holds retired code, the archive-not-delete rule that keeps names claimed, and how ownership moves are sequenced so no repository is momentarily readable by the wrong population.

## Three different end-of-life moves Repositories outlive their projects, and GitHub gives three distinct exits: **archive**, **transfer**, and **delete**. Confusing them in an interview is a small mistake; confusing them in production costs you a URL that a hundred systems depend on. ## Archive: freeze in place Archiving switches the repository to read-only across the board. Pushes are refused. Nobody can open issues or pull requests, comment on existing ones, or edit labels and milestones. Repository settings are locked. Automated maintenance stops as well — Dependabot no longer raises update pull requests and scheduled automation ceases, which is usually the point, because an unmaintained repository that keeps opening dependency pull requests is noise. What archiving does **not** do: it does not hide the repository (visibility is unchanged, so a public archived repository is still public and clonable), it does not free the name, and it is not permanent — an admin can unarchive and the repository returns to normal. Treat it as the default for "this project is finished but its history is worth keeping", and note that a banner tells visitors so, which saves the maintainers a stream of issues. ## Transfer: change owner Transfer moves a repository to a different user account or organization. The repository keeps its history, and its issues, pull requests, wiki, stars and watchers move with it. GitHub installs **redirects** from the old owner/name to the new one, so existing clone URLs and web links keep working — but treat those redirects as a grace period, not a permanent contract, and update remotes and CI configuration promptly. Requirements: admin on the repository being transferred, plus the ability to create repositories in the destination, and no name collision there. The most under-appreciated consequence is **access**: team grants live in the source organization, and they do not follow the repository. After a transfer you must re-grant access in the new owner's structure, and the new organization's base permission now applies — which can silently *widen* access if that organization has a permissive default. Repository settings that belong to the old organization's policy world — rulesets inherited at org level, org-level secrets and app installations — are likewise a re-do, so a transfer is a small migration rather than a rename. ## Delete: gone, and the name is released Deletion removes the repository. There is a short window in which GitHub can restore some deletions, but you should plan as though it is final. Deleting also **frees the name**, which is the sharp edge: a later account can claim the same owner/name path, and anything still pointing there resolves to someone else's repository. That is exactly why archiving is preferred for retired projects that other systems may still reference. ## Picking the right one Project finished, history worth keeping, name should stay claimed → **archive**. Project alive but owned by the wrong team or moving from a personal account into an organization → **transfer**, followed immediately by re-granting access and updating remotes. Repository created by mistake, empty, or a duplicate → **delete**. A useful combined move when a team is dissolved: transfer the repository to a long-lived organization first so the URL and ownership are stable, then archive it there. That preserves the link, keeps the name claimed, and stops the automation, all without anyone retaining push access to code nobody maintains. ## The bit interviewers probe The give-away question is "can you still clone an archived repository?" — yes, archiving is about writes, not reads. The second one is "who can read it after a transfer?" — not necessarily the same people, because access was expressed in the old organization's teams and did not travel.

  • Can you still clone and fork an archived GitHub repository?
    Yes — archiving affects writes, not reads. The repository keeps its visibility, so anyone who could read it before can still clone it, and its content stays indexed and linkable. What stops is everything that changes state: pushes, new or edited issues and pull requests, settings changes, and automated dependency updates.
  • After transferring a repository between organizations, why might the wrong people suddenly have access?
    Because access was expressed through the source organization's teams, which do not travel with the repository, while the destination organization's base permission applies immediately. If that base permission is write, every member of the new organization can push the moment the transfer completes. Re-establishing grants is part of the transfer, not an afterthought.
  • Why is archiving usually preferable to deleting a retired repository?
    Deleting frees the owner/name path, so a later account can claim it and anything still referencing that URL resolves to someone else's code. Archiving keeps the name claimed and the history readable while stopping all writes, and it is reversible. Delete is for mistakes and duplicates, not for retirement.

saying these in an interview costs you the question

  • Thinks archiving hides or unpublishes the repository
  • Believes archiving is permanent and irreversible
  • Assumes team access follows a transferred repository
  • Expects transfer redirects to last forever
  • Deletes a retired repo without considering the freed name

context

resolving links…