Git Sparse Checkout and Partial Clone

Git tracks a complete tree for each commit even when you choose to materialize only some paths locally. Sparse checkout changes working-tree visibility; it does not make a new commit deleting the other directories. git ls-tree can still describe the committed tree, and history commands can still inspect paths outside the selected area. Before interpreting an absent directory as deleted, check whether sparse rules are active and compare the committed tree with the working directory.

Partial clone instead negotiates an object filter with a remote. A common blob:none filter initially omits file-content blobs while retaining the objects needed to navigate history. Git may retrieve missing content when a checkout or another command needs it. The remote must support the requested behavior, and offline operations may fail when required objects have never been downloaded. A small initial clone is therefore not automatically a self-contained offline backup. State your network and server assumptions when recommending this optimization.

Cone mode describes a set of directories rather than arbitrary ignore-style patterns. Selecting apps/web includes that directory's descendants and the files immediately inside its ancestor directories. Root-level files such as README.md remain useful for build and repository instructions. Do not expect a cone selection to hide every file outside the deepest chosen directory. The predictable directory model makes the rules easier to explain and permits optimizations that general pattern matching cannot always use.

Use git sparse-checkout set with directory paths, then git sparse-checkout add when another directory becomes necessary. list shows the current selection; disable returns the working tree to a normal full checkout. These are local workflow settings, so teammates can select different directories while sharing the same commits. Keep the project build graph in mind: a frontend folder may depend on a shared package elsewhere. Selecting only the apparent entry folder can leave a perfectly valid repository unable to build in your chosen working tree.

Sparse rules are not a permission system. Commands can still access committed content outside the cone, and some operations may materialize paths to preserve work or present conflicts. Git takes care to avoid casually discarding modifications, but you should still inspect status before changing selections. If a merge introduces a conflict in an excluded directory, resolve the repository operation deliberately instead of assuming those paths are irrelevant to your branch.

A sparse index can represent unexpanded directories more compactly and improve some command performance. It is a separate optimization layered on sparse checkout, and compatibility varies across tools and versions. Begin with a straightforward cone checkout and confirm that your editor, build scripts and Git integrations behave correctly. If a tool requires a full index, consult Git's documented options for disabling sparse-index behavior while retaining path selection. Measure the actual bottleneck before adding another configuration that collaborators must understand.

For a new remote repository, a typical plan is git clone --filter=blob:none --sparse followed by an explicit sparse-checkout set. The clone filter controls object transfer; the sparse setting controls materialized paths. A server may reject or ignore filtering, so read the clone messages and inspect behavior rather than assuming the flag guarantees a particular download size. Local-path clones also have optimization rules that make them a poor substitute for a real server filter demonstration.

Document what happens when a developer expands the selection or searches historical content. Those operations may trigger new downloads, affect latency and need credentials. CI jobs that require the entire project should use a checkout strategy appropriate to that job rather than inherit a developer's narrow cone accidentally. For recovery or disconnected work, arrange to obtain all required content in advance and test the actual offline task. Optimization is successful when it reduces measured cost while preserving the operations your project needs.

First understand remotes, file management and worktrees. The official sparse-checkout reference explains cone and index behavior; clone documentation explains object filters and their prerequisites.