Compatibility Guidance

I am not pinning every feature in this book to an exact Git version.

Those details change over time, and different Git builds ship different commands, flags, and defaults. For the exact answer on your machine, check the docs for the Git you have installed.

Prefer a Recent Git

If you want the broadest large-repository feature set, use a recent Git release rather than an older vendor-patched build that may lag on commands, flags, or defaults.

The most version-sensitive parts of this book are:

• git backfill
• git filter-repo availability and packaging
• maintenance.strategy
• reftable and git refs
• Scalar availability and packaging
• fsmonitor and sparse-index integration details

Practical Checks

Before adopting a workflow from this book, confirm:

• the command exists in your build
• the flags you intend to use are present
• the feature is still marked experimental if that matters to your team
• your hosting provider and client both support the transport features you want

Useful checks include:

• git <command> -h
• git help <command>
• the matching versioned docs on git-scm.com

git --version
git refs -h
git maintenance -h
git filter-repo -h
git lfs version

Treat that as the first gate. Stock Git features and separately installed tools are different compatibility questions.

Features Most Likely to Vary

The features most likely to differ across Git builds or versions are:

• partial-clone and backfill workflows
• git filter-repo installation state
• maintenance strategy names and defaults
• ref-backend tooling such as reftable and git refs
• Scalar availability in your distribution
• background integrations such as fsmonitor

When to Name an Exact Version

Name an exact minimum version when:

• a command does not exist in older builds
• an option or default changed materially
• the feature is still experimental or backend-specific

Otherwise, prefer a paired rule:

• label the example newer Git only or separate install required
• show the verification command next to it

As of the current official docs, git-maintenance has versioned manual pages back to Git 2.29.0, and git-refs has versioned manual pages back to Git 2.46.0. Those are useful anchors, but git <command> -h on the target machine is still the faster truth source.

A Simple Rule

If you are teaching or standardizing Git across a team, prefer guidance like "use a recent Git and verify the current docs" over "this landed in version X" unless you really need the exact version number.