Versions & Releases

Uncommitted Work Across Repos: Did I Actually Save That?

Agents edit files in many repos and you forget to commit. How uncommitted work piles up, why it's risky, and a daily habit that keeps every repo clean.

By Tu Nguyen · · 2 min read.md

A developer in a hoodie rubs his forehead late at night beside a sleeping cat and a screen of open folders.

It’s late. You’re about to close the laptop. Then the thought: did I commit the book repo? The agent changed fourteen files there this afternoon. And the game repo — you fixed the ad bug, but did it get pushed?

You open a terminal and start the rounds: cd, git status, cd, git status…

Part 3 of Busy, Not Shipping. A day of real progress can still end with nothing saved.

Why it happens more with agents

Before agents, you changed files in one repo at a time and you felt every edit. Now an agent can touch dozens of files across several repos while you’re looking at something else. The work is real; the commit isn’t automatic.

Across a day of switching between projects, it’s easy to leave a trail of repos that are “done but not saved”.

Why it’s riskier than it looks

Uncommitted work fails quietly:

  • It only exists on this machine. Your other Mac, your CI, your future self on a new laptop — none of them see it.
  • It’s easy to wipe. A careless checkout, an agent told to “reset and try again”, a stash you forget.
  • It blocks the next task. Tomorrow’s session starts on top of a pile of mystery changes, and neither you nor the agent knows which ones were intentional.

A daily push, as its own step

Treat saving work as a separate, deliberate step — once a day, for every repo, in the same order:

  1. See all repos at once. Which ones are dirty? How many files?
  2. Review the file list. Is everything there meant to be there? Anything that looks like a secret?
  3. Write a message that says what changed — “store listing captions”, not “wip”.
  4. Push. Then move to the next dirty repo.

Doing this once a day is enough. It’s the same habit described in running 10 projects in parallel.

Keep status commits small

If your agent updates a state file after each task, commit that change on its own. A one-file commit that says “task X → phase 4” is easy to trust and easy to revert. Mixing it into a forty-file code commit hides it. When one repo holds many products, small commits also keep each product’s history readable.

What not to automate

Automate the seeing, not the judgment. Never let a script rebase, force-push or “clean up” across many repos for you. When a push fails, read the real error.

Where ShotMatic fits

Every ShotMatic board has a GIT strip that shows whether the repo is dirty and which files changed. Push shows the file list and a prefilled message first. ✓ on a task commits exactly one file, and ShotMatic never rebases or force-pushes.

FAQ

How do I check uncommitted changes across many git repos?

Run git status in each repo, or use a tool that shows a dirty/clean overview for all of them. The point is to see every repo at once, not to remember which ones you touched.

Should AI agents commit their own changes?

Small, well-defined commits can be fine, but review before you push. Never let a tool rebase or force-push for you across many repos.

How often should I push side projects?

At least once a day for every repo you touched. Work that lives only on one machine is one accident away from gone.

Keep reading