Multi-repo Git

How to manage many Git repositories.

Once you work across services, libraries, docs, examples, and infrastructure repos, the hard part is no longer one Git command. The hard part is knowing which repository needs attention without opening every folder.

Build an attention stack, not a tab collection

A useful multi-repo workflow ranks repositories by risk and actionability: dirty worktree, unpushed commits, behind upstream, divergence, active conflict, missing remote, submodule drift, or stale branch. The goal is to answer "what needs me now?" before you lose context switching across terminals.

Local changes

Identify dirty worktrees, staged files, untracked files, stashes, and uncommitted experiments before switching projects.

Remote drift

Separate ahead, behind, and divergent branches. They require different decisions and different levels of risk.

Workspace shape

Track submodules, worktrees, monorepo sparse checkouts, and partial clones without treating every repo as identical.

A practical checklist

  • Group repositories by product area or workspace instead of scanning your whole disk.
  • Prefer local status checks by default, and throttle automatic fetches to avoid noisy background work.
  • Flag divergent repositories higher than merely behind repositories because they require integration decisions.
  • Show submodule and worktree context near the parent repo so nested state is not missed.
  • Keep destructive operations scoped to one repository at a time unless the user explicitly confirms batch behavior.
FluxGit Fleet Radar

See repo drift before it becomes cleanup debt.

FluxGit includes Fleet Radar concepts for local-first repository status, attention stacks, and performance-conscious refresh. The beta is Windows first, and FluxGit does not send repository paths, remotes, commits, files, or diffs by default.