How to Manage Multiple Git Repos from One Terminal Workflow

The Challenge

Managing multiple repos is not a single problem. It is actually several problems tangled together:

• --Discovery: Where is that repo? Did I clone it already? What is it called?
• --Navigation: Getting into the right directory quickly.
• --Prioritization: Which of these 150 repos do I actually need right now?
• --Workspace setup: Opening the editor, starting dev servers, arranging terminal panes for the specific project.

Most tools solve one of these. A good workflow solves all of them together.

Directory Structure Best Practices

Before thinking about tooling, get your directory structure right. The most scalable pattern mirrors how GitHub organizes repositories: ~/dev/owner/repo.

This pattern has several advantages:

• +It matches your mental model of ownership. You know immediately which org a repo belongs to.
• +No naming collisions. Two different orgs can have a repo called api without conflict.
• +Fuzzy search works well because "mycompany/api" is unambiguous.
• +Tools like son and ghq adopt this layout by default.

Discovery and Sorting

Once your repos are organized, you need a way to list and search them. The simplest approach is a find command piped into fzf:

But alphabetical sorting is almost useless. You do not care about repos alphabetically -- you care about which ones you are actively working on.

Ranking by Activity (Frecency)

Frecency is a portmanteau of frequency and recency. The idea comes from browser history ranking: a page you visited 50 times last month but not since should rank lower than one you visited 5 times today.

You can approximate this with git. The most recent commit timestamp in a repo is a decent proxy for how recently you worked on it:

This gives you recency but not frequency. True frecency requires tracking both access count and access time over a window. Tools like zoxide do this for directories. son does it specifically for project selection, combining how often you open a project with how recently you opened it.

The f: score tells you at a glance which projects dominate your workflow. Projects you have not touched in weeks naturally sink to the bottom.

Favorites and Pinning

Frecency is great for daily work, but sometimes you have a project that you access infrequently yet want at the top of your list -- like an infrastructure repo you need during on-call. You can handle this with favorites or pinning.

Workspace Launch

Finding a repo is only half the battle. The other half is setting up your workspace for that specific project. Different projects need different things:

• --A Go API might need an editor pane, a server pane running go run ., and a test pane.
• --A React frontend might need npm run dev in one pane and a shell for git in another.
• --A monorepo might need panes for multiple services simultaneously.

You can define per-project workspace configs in a .son.toml file:

Now when you select api-gateway, son opens a split layout with your editor on one side and your server and test runners on the other. See the tmux split panes guide for more layout options.

Putting It All Together with son

Here is the complete workflow when everything is in place:

From thought ("I need to check the frontend") to a fully configured workspace in under a second. No directory navigation, no remembering paths, no manual pane setup. This is the difference between managing repos and having repos managed for you.