Git Professional

A monorepo stores many projects (services, libraries, apps) in a single Git repository; a polyrepo (multi-repo) gives each project its own repository. Neither is universally correct — the choice is about trade-offs.

• Monorepo — atomic cross-project commits, one place to change shared code, unified tooling and CI, easy large-scale refactors. But the repo grows huge, requires scaling tooling, and needs strict ownership controls.
• Polyrepo — small independent repos, clear boundaries, independent release cadence and access control. But cross-cutting changes span many PRs, and dependency/version drift is common.

Companies like Google and Meta run enormous monorepos with custom tooling; many open-source ecosystems remain polyrepo. Pick based on team size, coupling between projects, and the tooling you can invest in.

As repositories grow to gigabytes, a full clone downloads every version of every file ever committed, which is slow and wasteful. Partial clone lets the server omit some objects and fetch them lazily on demand.

• --filter=blob:none — a blobless clone skips file contents (blobs) until you actually check out or diff them. Commits and trees still come down.
• --filter=tree:0 — a treeless clone also skips trees, downloading them on demand. Smaller still, but more round-trips for history operations.

Partial clone dramatically reduces initial clone size and time, trading some up-front download for occasional on-demand fetches. It requires server support (modern GitHub, GitLab and Azure DevOps support it).

Even with a full or partial clone, you rarely need every directory checked out into your working tree. Sparse-checkout populates only the paths you select, keeping the rest of the tree absent on disk.

The modern cone mode (git sparse-checkout set --cone) is optimised for directory-based patterns and performs far better than legacy pattern matching on large repos, because Git can reason about whole directories rather than evaluating every path against a pattern list.

Combined with a blobless partial clone, sparse-checkout means a developer working on one service in a giant monorepo only downloads and materialises that service’s files.

Scalar is a tool that ships with Git to configure a repository with the best-known settings for very large repos. Instead of manually enabling each optimisation, scalar clone sets them up for you.

• Uses a partial (blobless) clone by default.
• Enables sparse-checkout in cone mode.
• Turns on background maintenance (commit-graph, pack repacking, prefetch).
• Enables fsmonitor so status and other commands avoid scanning every file.

Scalar is essentially a curated bundle of the large-repo features Git already has, applied automatically so teams get good defaults without expert tuning.

Operations like git log --graph, git merge-base and reachability checks must repeatedly walk commit history. The commit-graph is an auxiliary file that stores commit metadata (parents, generation numbers, commit dates) in a compact, indexed form so Git can answer these queries without parsing every commit object.

On large repos the commit-graph turns history traversals that took seconds into near-instant operations. Generation numbers let Git prune walks early when it can prove a commit cannot be an ancestor.

Two features keep day-to-day Git fast on huge repositories.

• fsmonitor watches the filesystem (via a built-in daemon or Watchman) and tells Git exactly which files changed, so git status does not have to lstat() every file in a tree of hundreds of thousands of paths.
• Background maintenance (git maintenance start) runs scheduled tasks — incremental repacking, commit-graph updates, loose-object cleanup and prefetch — so the repository stays optimised without a developer manually running git gc.

Together they keep interactive commands snappy regardless of repository size.

Git stores a monorepo, but it does not build or test it intelligently. Monorepo build tools add a dependency graph and caching so CI only rebuilds what actually changed.

• Nx and Turborepo — JavaScript/TypeScript-focused. They compute the affected project graph from changed files, run only affected tasks, and cache task outputs (often remotely shared across the team and CI).
• Bazel — language-agnostic, hermetic builds with explicit dependency declarations and aggressive content-addressed caching; used for very large polyglot monorepos.

The shared idea is the affected/incremental build: use the change set plus a dependency graph to skip work whose inputs are unchanged.

Semantic Versioning (SemVer) gives releases a meaningful MAJOR.MINOR.PATCH number so consumers can reason about compatibility.

• MAJOR — incremented for incompatible (breaking) API changes.
• MINOR — incremented for backward-compatible new functionality.
• PATCH — incremented for backward-compatible bug fixes.

Pre-release identifiers (1.0.0-rc.1) and build metadata (+build.5) extend the scheme. A clear SemVer policy — documented and enforced — lets downstream teams pin dependencies and trust that a patch upgrade will not break them.

Conventional Commits is a lightweight convention for commit messages that machines can parse. The format is type(scope): description, optionally followed by a body and footers.

• feat: a new feature (maps to a MINOR bump).
• fix: a bug fix (maps to a PATCH bump).
• A ! after the type or a BREAKING CHANGE: footer signals a MAJOR bump.
• Other types: docs, chore, refactor, test, ci, etc.

Because the type carries semantic meaning, tooling can derive the next version number and generate changelogs automatically.

A convention that is not enforced quickly erodes. commitlint checks that commit messages follow a configured rule set (commonly config-conventional) and rejects messages that do not.

It is typically wired into a commit-msg Git hook (often via Husky) so a non-conforming message is blocked locally, and also run in CI as a backstop on pull requests. Enforcement at commit time gives fast feedback; the CI check guarantees nothing slips through regardless of a contributor’s local setup.

semantic-release automates the whole release process from Conventional Commits. On each run (usually in CI on the main branch) it:

• Analyses commits since the last release to determine the next version (patch/minor/major).
• Generates release notes and updates the changelog.
• Tags the release in Git and publishes artifacts (e.g. to npm) and a GitHub/GitLab release.

The key principle: the version number is derived from commit history, not chosen by a human. This removes guesswork and makes releases reproducible. If no relevant commits exist, no release is published.

Branch protection rules guard important branches (like main) on a hosting platform. Typical protections include:

• Require pull requests before merging (no direct pushes).
• Require a minimum number of approving reviews.
• Require status checks (CI, tests) to pass before merge.
• Require branches to be up to date with the base before merging.
• Restrict or forbid force pushes and branch deletion.

These are enforced by the host, not by Git itself, so they apply to everyone pushing through that platform. They are the backbone of code-quality and change governance.

A CODEOWNERS file maps file paths to the individuals or teams responsible for them. When a pull request touches a matching path, the host automatically requests a review from the listed owners, and — when combined with branch protection’s “require review from Code Owners” — their approval becomes mandatory before merge.

Patterns work like gitignore globs, and the last matching pattern wins. CODEOWNERS is how large organisations route reviews to the right experts and enforce that sensitive areas (security configs, infrastructure) are always reviewed by their owners.

Commit authorship metadata is trivially forgeable — anyone can set user.name and user.email to anyone. Cryptographic signing proves a commit or tag really came from the holder of a key.

• GPG — the traditional approach; sign with a GPG key registered on the host.
• SSH signing — reuse an existing SSH key (gpg.format ssh); simpler key management since teams already have SSH keys.

Hosts show a Verified badge when a signature matches a key registered to the author. Organisations can require signed commits via branch protection so unverified commits are rejected.

Managing long-lived GPG/SSH keys across an org is painful. Sigstore enables keyless signing: gitsign signs a commit using a short-lived certificate issued by Sigstore’s Fulcio CA after you authenticate with an OIDC identity provider (e.g. your GitHub or Google login).

The signing record is logged in the Rekor transparency log. Because the certificate is ephemeral, there is no private key to rotate, store or leak — identity is bound to your OIDC account at signing time. This fits cleanly into CI, where a workflow can sign with its OIDC token.

The cheapest secret leak is the one that never lands. Stop secrets before they are committed and as a CI backstop.

• Pre-commit scanning — tools like gitleaks or detect-secrets run in a pre-commit hook and block a commit that contains high-entropy strings or known credential patterns.
• CI scanning — the same scanners run on pull requests so nothing slips through if a developer skipped the local hook.
• Host secret scanning + push protection — platforms can reject a push that introduces a recognised secret.

Defence in depth: local hooks give fast feedback, CI and host scanning guarantee coverage.

If a secret reaches a repository, the first and most important step is to rotate (revoke and replace) the credential. Once a secret has been pushed — especially to a shared or public host — assume it is compromised: it may be in clones, forks, caches, CI logs and backups that you cannot rewrite.

Rewriting history to scrub the secret is still worthwhile to limit further exposure, but it does not make the leaked value safe. The correct order is: rotate the secret first, then rewrite history, then force everyone to re-clone, then verify the secret no longer works.

To purge a file or secret from all history you must rewrite commits. Two modern tools do this:

• git filter-repo — the recommended, fast and flexible tool (replaces the deprecated filter-branch). It can remove paths, replace text, and prune empty commits.
• BFG Repo-Cleaner — simpler and very fast for the common cases of deleting large files or replacing secret strings.

Rewriting changes commit SHAs for everything after the touched point, so all collaborators must re-clone or hard-reset. Remember from the previous lesson: rotate the secret first — history rewriting reduces exposure but never makes a leaked credential safe.

At scale, access is managed through organisations (or groups), teams and roles rather than per-user grants on each repo.

• Organisations/Groups own repositories and billing and set org-wide policy.
• Teams bundle members; you grant a team a permission level on a set of repos so adding a person to a team grants all the right access at once.
• Roles (Read, Triage, Write, Maintain, Admin on GitHub; Guest…Owner on GitLab) define what each member can do.

The guiding principle is least privilege: grant the minimum role needed, prefer team-based grants over individual ones, and review access regularly.

Enterprises centralise identity so accounts are provisioned and de-provisioned in one place. SSO via SAML (or OIDC) ties repository-host access to the corporate identity provider (Okta, Entra ID, etc.).

• A user must authenticate through the IdP to access org resources.
• When someone leaves, disabling their IdP account immediately cuts off Git access — critical for offboarding.
• SCIM can automatically provision and de-provision team membership.
• Personal access tokens and SSH keys can be required to be SSO-authorised so they too respect the IdP.

This makes access governance enforceable and auditable across the whole organisation.

Regulated and security-conscious organisations must answer “who did what, when?”. Hosting platforms provide audit logs recording events such as permission changes, branch-protection edits, secret access, repo creation/deletion and member changes.

• Stream audit logs to a SIEM for retention, alerting and correlation.
• Combine with signed commits and protected branches to produce a defensible change record.
• Many frameworks (SOC 2, ISO 27001) expect evidence that changes are reviewed, attributed and traceable.

The Git history itself is part of the evidence, but governance also relies on the host’s tamper-evident audit trail of administrative actions.

Branches are not the only refs worth protecting.

• Protected tags — release tags (e.g. v*) can be locked so they cannot be created, overwritten or deleted except by authorised users. This stops a published release tag from being silently moved to point at different code.
• Deployment environments — hosts let you define environments (staging, production) with required reviewers, wait timers and environment-scoped secrets. A deploy to production can require manual approval, and its secrets are never exposed to other jobs.

Together these make the release-to-deploy path governed, not ad hoc.

CI runs Git operations constantly, so efficient integration matters.

• Triggers — pipelines run on events: pushes, pull requests, tags, schedules or manual dispatch. Tag triggers commonly drive releases.
• Shallow clones — --depth=1 fetches only the latest commit(s), speeding up checkout when full history is not needed.
• Caching — cache dependencies and build outputs keyed by lockfile hashes to avoid redundant work.

Be careful: a shallow clone lacks history, so steps needing it (e.g. computing changed files against a base, or release tooling) must fetch-depth: 0 or unshallow first.

Storing long-lived cloud credentials as CI secrets is a major risk. OIDC lets a CI job exchange a short-lived, signed identity token for temporary cloud credentials — no static secret stored.

• The CI provider issues a signed OIDC token describing the workflow, repo and branch/environment.
• The cloud (AWS/GCP/Azure) trusts that issuer and, if the token’s claims match a configured policy, returns short-lived credentials.
• You can scope trust to a specific repository and even a specific environment or branch.

This removes the most commonly leaked class of secret and ties access to the actual workload identity.

GitOps applies Git workflows to operations: the desired state of infrastructure and applications is declared in a Git repository, and an automated agent continuously reconciles the live system to match that repository.

• Git is the single source of truth; changes happen via pull requests, giving review, audit and easy rollback (just revert a commit).
• A controller (e.g. Argo CD, Flux) pulls the declared state and applies it, detecting and correcting drift.

Because every change is a reviewed, attributed commit, GitOps inherits Git’s governance: history, blame, signatures and protected branches all apply to your infrastructure.

Git is built for text and performs poorly when large binaries are committed directly, because every version is stored forever and bloats every clone.

• Git LFS (Large File Storage) replaces large files in the repo with small text pointers; the actual bytes live in a separate LFS store and are fetched on checkout. Good when binaries are genuinely part of the source and must be versioned alongside code.
• Artifact stores (e.g. a package registry, S3, Artifactory) keep build outputs and large assets outside Git entirely, referenced by version. Better for derived artifacts that should not live in source control at all.

Policy rule of thumb: version source inputs (with LFS if large); publish derived artifacts to an artifact store.

Consistency across many repos comes from templates and shared standards, not manual setup each time.

• Template repositories let new repos start with a curated baseline: directory layout, CI workflows, linters, license, CODEOWNERS and security policy.
• Org-level defaults (e.g. a .github repo) provide default community health files (CONTRIBUTING, issue/PR templates, security policy) to every repo that lacks its own.
• Standards as code — shared lint configs, reusable CI workflows and policy checks keep repos aligned as they evolve.

This reduces drift, speeds onboarding, and ensures every new project inherits the org’s guardrails.

Clear contribution guidance lowers friction and raises quality.

• CONTRIBUTING.md explains how to set up the project, branch and commit conventions, how to run tests, and the review/merge process.
• Pull request templates pre-fill the PR description with a checklist (tests added, docs updated, breaking changes noted), nudging contributors to provide what reviewers need.
• Issue templates structure bug reports and feature requests so triage is faster.
• A CODE_OF_CONDUCT sets behavioural expectations, especially for open projects.

These documents encode tribal knowledge so newcomers can contribute correctly without asking a maintainer each time.

“Every clone is a backup” is only partly true — it omits server-side data (issues, PRs, settings, LFS objects, wikis) and may be stale. A real DR plan is deliberate.

• Mirror clones — git clone --mirror captures all refs; schedule regular git fetch on the mirror to keep it current and stored off-platform.
• Bundles — git bundle packages history into a single file for offline/cold storage.
• Platform backups — export issues, PRs, permissions and settings via the host’s API, since those live outside Git.

Test restores periodically — an untested backup is a hope, not a plan.

Moving repositories without losing history is a common enterprise task.

• Host to host — a --mirror clone followed by a mirror push transfers all branches and tags. Issues, PRs and permissions need separate API-based migration since they are not in Git.
• From SVN — git svn clone imports SVN history into Git, optionally with an authors map so SVN usernames become proper Git author identities. For large/complex migrations, dedicated importers (e.g. reposurgeon) handle branches/tags more faithfully.

Validate after migrating: compare commit counts, tags and key file checksums between source and destination.

A bad push --force can overwrite commits on a shared branch. Recovery hinges on the fact that Git rarely deletes objects immediately.

• Reflog — git reflog records where refs pointed locally; the overwritten commit is usually still reachable by its old SHA, so you can reset or re-push it. Note the reflog is local, so recovery is easiest from a clone that still has the old tip.
• Prevention — require --force-with-lease (which refuses if the remote moved unexpectedly), forbid force pushes on protected branches, and keep mirrors so a server tip is recoverable.

Because force-push damage is often unrecoverable on the server alone, prevention plus off-platform mirrors is the real safety net.

Sharing code across repos is often done with submodules or subtrees, and each needs governance.

• Submodules embed another repo as a pinned commit reference. They keep histories separate and pin an exact version, but contributors must git submodule update --init, and forgetting to bump or commit the pointer causes confusion. Govern by documenting update procedures and pinning to reviewed commits.
• Subtrees merge another project’s history into a subdirectory of your repo. No extra clone step, but the host repo grows and updates use git subtree pull.

Choose deliberately: submodules for clean separation and exact pinning; subtrees for a single self-contained clone. Document the chosen workflow so the team handles updates consistently.

Large, long-lived repos degrade without upkeep. A maintenance policy defines what runs, when, and how performance is monitored.

• Repacking and gc — consolidate loose objects into packs and drop unreachable ones (typically via scheduled git maintenance rather than ad hoc git gc).
• Commit-graph upkeep — keep the commit-graph current for fast history operations.
• Monitoring — track clone time, repo size, pack count and fetch latency; alert on regressions.
• Hygiene rules — ban large-binary commits (use LFS/artifact stores), prune stale branches, and keep history clean.

Treating repo health as an SLO keeps developer experience fast as the codebase grows.

Git is not only for application source. Treating other assets as code (docs-as-code, everything-as-code) brings the same governance — review, history, and CI — to non-code content.

• Documentation — Markdown docs in Git get PR review, versioning and link-checking/build pipelines (static site generators publish on merge).
• Configuration and policy — infrastructure, runbooks and policies live in Git so changes are reviewed and auditable.
• Considerations — for binary-heavy content (images, designs) apply the large-binary policy; non-technical authors may need a friendlier editing layer (a CMS or web editor that commits on their behalf).

The payoff is one consistent change-management model across code and everything around it.