Ask an engineering organisation with two thousand repositories how many have no owner. Most cannot answer, and the ones that can are the ones that built the inventory.
That question is the whole of this cluster. A repository fleet is not a large number of repositories — it is a system with its own operational discipline, and the discipline starts with being able to enumerate and describe what you have.
Start with Repository Fleet ManagementWhat this cluster answers
Section titled “What this cluster answers”A fleet is a system
Section titled “A fleet is a system”A node labelled repository fleet branching to seven concerns: ownership, metadata, policy, CI/CD, security, dependencies and lifecycle.
Repository Fleet │ ├── Ownership → a named team, accountable ├── Metadata → what it is, how critical, what data ├── Policy → which rulesets apply ├── CI/CD → which shared workflow, at which version ├── Security → scanning, secrets, alerts triaged ├── Dependencies → what it consumes, what is vulnerable └── Lifecycle → active, maintained, archived, orphanedEvery column is trivial for one repository and impossible for a thousand without automation. That gap is the discipline.
The characteristic failure is drift. No individual repository is wrong; the set has diverged. A workflow pinned to a version withdrawn a year ago. Forty repositories on an unsupported runtime. Twelve with no CODEOWNERS. Nothing failed, nothing alerted, and the aggregate is a risk invisible from any single repository.
Inventory comes first
Section titled “Inventory comes first”The ordering this cluster insists on, because reversing it is the most common way a fleet programme stalls.
You cannot govern what you cannot enumerate. A policy targeting data_classification: restricted reaches nothing if no repository has the property set. A template improves new repositories and does nothing for the existing two thousand. An access review needs a list of what access is to.
So the sequence is:
Inventory — what repositories exist, from the API rather than from anybody’s memory.
Ownership — who is accountable for each. This is an organisational exercise and it is where the real work is; the technical part is a property field.
Classification — service tier, data classification, production or not, using custom properties.
Then everything else — policy that targets the classification, standards enforced against the inventory, lifecycle decisions informed by both.
The instinct to skip to policy is strong because policy feels like the lever. It is, and it is a lever with nothing attached to it until the first three steps are done.
Templates start; they do not maintain
Section titled “Templates start; they do not maintain”The misunderstanding that produces the most disappointment in this cluster.
Templates establish a starting point. They do not automatically keep existing repositories synchronised forever.
A repository created from a template two years ago has that template as it was two years ago. Improving the template changes nothing about it, and nothing reports the gap.
Closing that gap requires a different mechanism, and there are three:
A drift report — a scheduled job listing repositories missing an expected file or setting. Reports, changes nothing, and is the cheapest thing that works.
Automated pull requests — a bot proposing the update, which teams review and merge. Real work to build, and it actually converges the fleet.
Organisation-level configuration — rulesets and policies that apply centrally without touching each repository. The strongest option, and it only covers things GitHub exposes at that level.
Repository templates covers all three, and the honest conclusion that templates plus organisation-level settings plus a drift report is the combination that works.
Reusable workflows are how CI stays consistent
Section titled “Reusable workflows are how CI stays consistent”A central platform repository containing a reusable workflow, consumed by four repositories A, B, C and D each referencing it by tag.
Central Platform Repository │ Reusable Workflow (tagged v4.2.0) │ ┌────┼────┬────┐ ↓ ↓ ↓ ↓ Repo A Repo B Repo C Repo D @v4 @v4 @v4 @v3 ← one repository is behindThe version reference is the whole design. Consumers referencing @main get changed underneath them with no pull request anywhere to notice; consumers referencing a tag upgrade deliberately.
And the repository on v3 in that diagram is the fleet problem in miniature — nothing is broken, nothing alerted, and the platform team’s improvements have not reached it. Finding those repositories is a query; getting them upgraded is a programme.
Standardised CI/CD covers the mechanics, and cross-links Pillar 4’s reusable workflows for the syntax.
Migration is a programme, not a command
Section titled “Migration is a programme, not a command”Three articles, deliberately separated by search intent.
GitHub Enterprise Importer — the tool. What it migrates, what it does not, its documented size limits, and which source and destination combinations are supported.
Migration planning — the methodology. Inventory, classification, identity mapping, pilot, waves, validation, cutover, decommission.
Migration automation — the implementation. Batch migrations, monitoring, retries, and validation reporting.
Lifecycle signals, and the danger of acting on one
Section titled “Lifecycle signals, and the danger of acting on one”A repository fleet accumulates dead weight, and identifying it is a judgement rather than a query.
Signals that a repository may be inactive:
No commits in twelve months. No open or recently closed pull requests. No CI runs. No owner, or an owner who has left. An unsupported language runtime. Unaddressed dependency alerts. Documentation referencing systems that no longer exist. No deployments.
Not one of these is sufficient on its own. A library that is finished has no commits and is depended upon by forty services. A repository with no CI may be documentation. A repository with no recent activity may hold the disaster-recovery procedure somebody needs once every three years.
Combine signals and ask a human. Three or four signals together is a strong candidate for archival; any single one is a question worth asking the owning team.
Archive rather than delete, almost always. Archiving makes a repository read-only and preserves everything; deletion is irreversible and the cost of being wrong is unbounded. Deletion belongs at the end of a retention period, after archival, with a record of the decision.
Learning objectives
Section titled “Learning objectives”By the end of this cluster you should be able to:
- Build a repository inventory from the API and keep it current
- Design an ownership model where every repository has an accountable team
- Explain why templates do not maintain existing repositories, and choose a mechanism that does
- Standardise CI across a fleet using versioned reusable workflows without breaking consumers
- Define lifecycle states and the signals that move a repository between them
- Compare GitHub Enterprise Cloud and Enterprise Server on the dimensions that actually differ
- State what GitHub Enterprise Importer migrates, what it does not, and its size limits
- Plan a migration in waves with a pilot, a freeze window and a validation checklist
- Automate batch migrations with monitoring, retries and a validation report
Enterprise use cases
Section titled “Enterprise use cases”An acquisition. Several hundred repositories on another platform, unknown shape, needing assessment, migration and integration into the corporate governance model.
A platform consolidation. Moving from GitHub Enterprise Server to Enterprise Cloud, or the reverse for a data-residency requirement.
A security programme. “Every production repository must have branch protection and a code owner” — which requires knowing which repositories are production.
A cost or licence review needing an accurate count of what is active versus abandoned.
A runtime deprecation. An end-of-life language version, requiring a list of every repository using it and a campaign to upgrade.
Repository sprawl. Growth of 40% a year, no archival, and an estate where nobody can say what half of it is for.
Fleet automation must be safe by construction
Section titled “Fleet automation must be safe by construction”The engineering standard this cluster holds to, because a script that touches a thousand repositories is a script that can break a thousand repositories.
Read-only first, always. Build the inventory before building anything that changes it. Most fleet value is in knowing rather than in changing, and the read-only phase is where you discover your assumptions were wrong.
Every mutating tool needs a dry run, and the dry run must show the target set. “This would modify 412 repositories” is the moment somebody notices the filter is wrong.
Show, confirm, then act. A preview of what will change, an explicit confirmation, and only then the change.
Log every intended change, not just the failures. When a run half-completes you need to know exactly where it stopped.
Be restartable. A job that fails at repository 250 of 400 must be resumable without redoing the first 250 or skipping them.
Handle failures per item. One repository erroring should not abort the batch; it should be recorded and reported at the end.
Rate limit deliberately. A tool that hammers the API until it is throttled will half-complete and look like a bug.
Scope the credential. A GitHub App with the specific permissions the task needs, not a personal token with organisation admin. Machine identities covers the choice.
The shape that follows is a tool with --dry-run by default, a filter, a limit, structured output and a resume mechanism — and enterprise API automation covers building one.