Why Multi-Repo Git Workflows Break Down
Modern development often means juggling many small repositories:
microservices, shared libraries, tooling repos, and experiments.
Git works extremely well at the single-repo level.
Once you scale beyond that, context is what breaks first.
I kept running into the same issues:
- Losing track of which repos were dirty
- Jumping between different project trees
- Restarting tools just to change directories
- Symlinked workspaces behaving inconsistently
This post is a short case study on how that led to git-scope v1.3.0.
Constraints That Shaped the Solution
Before writing code, I set some firm constraints:
- Terminal-first
- Local-only (no cloud, no telemetry)
- Read-only by default
- Composes with existing tools (editors, lazygit, shell)
git-scope is intentionally a lens, not a control panel.
Why Workspace Switching Was Necessary
Originally, git-scope relied on configured root directories.
That worked until real workflows got messy.
Switching contexts meant:
- Quitting the app
- Editing config
- Restarting
That breaks flow.
v1.3.0 introduces in-app workspace switching so you can move between
repo trees without restarting or reconfiguring anything.
Handling Real-World Filesystems (Symlinks)
Many setups rely on symlinks:
- Codespaces
- External drives
- Dotfile-based workspaces
If cd works, the tool should work.
v1.3.0 resolves paths explicitly so absolute paths, relative paths,
and symlinked directories behave consistently.
What I Deliberately Didn’t Build
Just as important as what shipped is what didn’t:
- No git write operations
- No file browsing
- No team dashboards
- No telemetry or background services
The goal is clarity, not control.
Outcome So Far
Workspace switching removed a real daily friction for me.
More importantly, it clarified what git-scope is supposed to be:
a calm overview of many repos, not another git client.
Closing Thoughts
Many teams end up building internal tooling to deal with repo sprawl.
git-scope is my attempt to make one of those tools reusable,
without losing the simplicity that made it useful.
Closing Thoughts
Many teams end up building internal tooling to deal with repo sprawl.
git-scope is my attempt to make one of those tools reusable,
without losing the simplicity that made it useful.
Top comments (1)
check the latest version 1.3.0 and kindly share the feedback.