Workflows
Sparse-checkout and worktree flow for monorepos
Use sparse-checkout and worktree together in a monorepo to reduce context load and support parallel task work without loading the whole tree every time.
- Teams turning commands into repeatable routines
- Readers who need sequencing, branch, and sync discipline
- Basic understanding of fetch, pull, push, and branches
- A sense of how and why branches diverge
- Copying a workflow without checking branch state
- Choosing the wrong integration path on shared branches
In a monorepo, the pain is often not Git itself. The pain is scope.
Two tools help a lot:
sparse-checkoutto limit the active directory surfaceworktreeto open a second working copy for parallel tasks
A common scenario
packages/frontend/packages/backend/packages/shared/docs/infra/
wt-frontend/ → only frontend + sharedwt-backend/ → only backend + sharedEach worktree contains only relevant dirs
Cone mode sparse-checkout performs better. Combined with worktree for true parallel monorepo development.
You only need the frontend app, but the repo also contains backend services, infra code, tooling, and shared packages.
A practical flow
git sparse-checkout init --cone
git sparse-checkout set apps/web packages/ui
git worktree add ../repo-hotfix hotfix/login-fix
That lets you:
- keep the main working tree focused
- handle a hotfix in parallel
- avoid pulling the full repo surface into daily attention
Boundary with submodules
If this is one monorepo, prefer sparse-checkout and worktree first.
If you are managing true repository-to-repository dependencies, then submodule may be the more relevant tool.
One principle
In large repositories, workflow quality improves when the active scope becomes explicit and small.