H.1 Repository

Two directories can sit beside each other while belonging to different products, teams, access domains, and delivery systems. Conversely, source in separate repositories can participate in one composed build. The repository question is narrower: which source and change history share one control boundary, and what guarantees does that boundary provide?

Compare Guarantees, Not Labels

H.1.1 Repository Models compares mono-, multi-, and hybrid arrangements by atomic source change, global discovery, access, external contribution, governance, and operating cost. It prevents “monorepo” from silently acquiring unrelated promises such as one deployment, one solver, or unrestricted edges.¹

Once the boundary is named, H.1.2 Repository Contents inventories what Git should actually carry. Authored source, generated output, third-party code, fixtures, large data, models, and build products have different review, retention, access, availability, and offline needs. A pointer to an external object does not move those operating obligations out of the system.

H.1.4 Repository Topology gives directories, namespaces, project boundaries, and paths an explicit design contract without pretending that team, build, deployment, and filesystem boundaries must coincide. H.1.5 Information Lifecycle then follows source and history into archives, mirrors, indexes, caches, backups, and exports where retention or removal must still be verified.

A Boundary Change Is A Program

Suppose a separately governed service moves into a primary repository. The move is not complete when files appear under a new directory. History, ownership, review rules, dependency names, automation, credentials, artifacts, external consumers, and rollback all refer to the old boundary. H.1.3 Boundary Changes chooses the destination and records which guarantees must survive or be replaced. H.6 Migration owns the reusable operating model for executing that transition through cohorts, automation, progress control, and cleanup.

Read Repository Models when the steady-state boundary is undecided, Repository Contents when the question is “does this kind of material belong in Git?”, Repository Topology when paths and namespaces are the interface under pressure, and Information Lifecycle when history or derived copies must be retained or removed. Boundary Changes owns the target state when two boundaries differ.

Footnotes

1. Advantages and Disadvantages of a Monolithic Repository: A Case Study at Google — observed benefits and costs of a shared source boundary ↩