Skip to main content
3 days of team commits lost

Git destruction

2025. 3 days of team commits lost.

An AI coding agent was asked to “fix the merge conflicts and get main up to date.” It ran git push --force to main, overwriting three days of commits from four other developers. The reflog had the old HEAD, but by the time anyone noticed, two developers had already pulled the rewritten history.

What happened

Three separate incidents show the same pattern. Agents reaching for the most destructive git command available:

Force push to main. A developer asked their agent to resolve diverged branches. The agent ran git push --force origin main, overwriting the remote history. Three days of commits from four developers were lost. Recovery required manually cherry-picking commits from individual developer machines.

git reset —hard. A developer asked their agent to “undo the last change.” The agent ran git reset --hard HEAD~3, destroying three commits of uncommitted and staged work. The developer lost hours of in-progress changes that existed only in their working tree.

git clean -f. A developer asked their agent to “clean up the repo.” The agent ran git clean -fdx, permanently deleting untracked test fixtures, local configuration files and a .env.local that was not checked in. These files were not recoverable from git history because they had never been committed.

Why it works

Git’s destructive commands are designed for specific expert workflows. --force exists for rebasing feature branches. reset --hard exists for discarding known-bad changes. clean -f exists for resetting to a pristine state in CI.

AI agents do not understand these contexts. They see the commands as the fastest way to accomplish the stated goal. “Get main up to date” becomes push --force. “Undo the last change” becomes reset --hard. “Clean up” becomes clean -f. The agent optimizes for task completion, not safety.

Which rules block this

Three Vectimus rules cover git destruction:

  • vectimus-git-001: Blocks git push --force to main, master and production branches. Feature branch force-pushes are still allowed.
  • vectimus-git-002: Blocks git reset --hard. The deny response suggests git stash or git revert as safe alternatives.
  • vectimus-git-003: Blocks git clean -f. The deny response suggests reviewing untracked files with git clean -n (dry run) first.

Each rule tells the agent what to do instead. The agent can still accomplish the task, just not with the destructive shortcut.

What to learn from this

Git’s destructive commands exist because experienced developers sometimes need them. But an AI agent is not an experienced developer making a judgment call. It is a language model picking the shortest path. Vectimus blocks the irreversible git operations and redirects the agent to safe alternatives. You can always run git push --force yourself. The policy ensures the agent cannot. See the writing policies guide for customising git rules and configuration for adjusting which branches are protected.

Sources

This post is based on a recurring pattern documented across multiple GitHub issues.