# 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.

- URL: https://shotmatic.app/blog/uncommitted-work-across-repos
- Category: Versions & Releases
- Published: 2026-10-08
- Author: Tu Nguyen

## Key takeaways

- AI agents change files in several repos a day, and it's easy to end the day with work that exists only on one laptop.
- Uncommitted work is the most common way multi-project setups lose work: a wiped branch, a dead disk, a second machine that never sees it.
- Check every repo for uncommitted changes once a day, review the file list, and push — as a separate, deliberate step.
- Keep status commits small and separate from code commits so each one is easy to trust.

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](https://shotmatic.app/blog/context-switching-too-many-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](https://shotmatic.app/blog/run-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](https://shotmatic.app/blog/one-repo-many-products-versioning), 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.