Code Repository

Origin & evolution

Version control predates the word "repository" in its modern sense. The Source Code Control System (SCCS, 1972) and the later Revision Control System tracked individual files, storing changes as space-efficient deltas. CVS, widely used from the 1980s, added a central repository many developers could check out from and commit to, and Subversion (2000) refined that same centralised model with atomic commits across a whole tree. The constant through this lineage was a single authoritative server; your local copy was a working snapshot, and history lived in one place.

Git broke that assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference →. Linus Torvalds began writing it in April 2005, after the Linux kernel project lost free access to the proprietary BitKeeper tool it had relied on. He had it self-hosting within days. Git gave every developer a full copy of the entire history, so the repository stopped being a place on a server and became a thing you held locally and synchronised with others. That distributed design, shared with contemporaries like Mercurial and Bazaar, won decisively; surveys now put Git's share among developers near 95 percent.

Chacon and Straub's Pro Git is the standard technical account of what that distributed design means in practice: every clone holds a full object database — blobs, trees, commits, and tag objects, each addressed by the hash of its content — with branches and other refs as lightweight pointers into it. Because that history lives locally rather than on the tip alone, a repository can be forked, mirrored, or moved to a new host without losing it, and operations like log, diff, and blame run entirely offline; the server is needed only to exchange objects, not to compute answers about the past.

With cheap, fast repositories came a structural question that is still live: how many should a system have? The monorepo keeps many projects or services in one repository, which makes cross-cutting changes atomic and dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → consistent, at the cost of coarse access control and heavier tooling. The polyrepo gives each service its own repository with its own pipeline and permissions, buying team autonomy and clean isolation, at the cost of coordinating changes that span several repos. Neither wins on principle. The honest framing, well argued in Joel Parker Henderson's monorepo-vs-polyrepo notes, is that the right structure matches your team structure and your deployment📤DeploymentEngineeringA deployment eventView reference → patterns, which is Conway's Law showing up in the layout of your version control: repository boundaries drift toward communication boundaries whether you plan it or not.

Forsgren, Humble, and Kim's Accelerate adds an empirical angle: their analysis of State of DevOps survey data links trunk-based development with short-lived branches and small batch sizes to better software delivery throughput — specifically the two speed measures, deployment frequency and lead time for changes. By that reading the repository-structure question is not only organisational; how a team segments its code shapes the feedback loops it can run, so choosing between monorepo and polyrepo on team-boundary grounds alone may still leave delivery speed on the table.

How it works in practice

A fintech company runs four squads. They start polyrepo, one repository per service, eighteen repos in all. Within a year a recurring pain emerges: a change to the shared money-formatting library means a pull request in the library repo, a published version bump, then four more pull requests across consuming repos, often merged days apart, with a window where services disagree about how to round a currency. They consolidate the four most tightly coupled services and the shared library into one monorepo. Now a single pull request changes the library and all its callers atomically, and the CI pipeline🚇CI PipelineDevOps & PlatformA CI/CD pipelineView reference → tests the whole set together. The two genuinely independent services, owned end to end by one squad each, stay in their own repos, because their boundary really is a team boundary and the isolation is worth keeping.

Code repository vs. its neighbours

• Bounded context🔲Bounded ContextEngineeringA DDD bounded context defining a service boundaryView reference → is a domain concept from Domain-Driven Design: a region of the model with its own consistent language. A repository is a storage and ownership concept. They often align, one repo per bounded context, but the repo is the physical boundary and the bounded context is the conceptual one; conflating them hides the cases where they should not match.
• CI pipeline reads from the repository and runs on its changes. The repository is the durable source of truth; the pipeline is the activity triggered by writes to it.
• Deployment takes a version drawn from the repository and installs it. The repo holds every version that ever existed; a deployment selects exactly one.

In the graph

In the Unified Product Graph, a code repository sits in the engineering region as a unit of ownership and physical structure. A product🧬ProductStrategyThe product being created, the root of the graphView reference → connects through product_stored_in_code_repositoryProductstored inCode Repositoryhierarchy, and the more telling edge is bounded_context_stored_in_code_repositoryBounded Contextstored inCode Repositoryhierarchy, which records exactly where a domain boundary meets a storage boundary. Making that edge explicit lets you query the cases the prose above warns about: a bounded context split across two repos, or two contexts crammed into one. Because Conway's Law pulls repository boundaries toward team boundaries, modelling the repo as its own node keeps that organisational reality visible alongside the architecture, where a folder tree would bury it.