Check AI Git Commands Before You Run Them

You will be able to read Git commands from an AI assistant, spot the ones that delete work, and pick safer choices.

Why read a Git command before running it?

AI assistants are good at producing Git commands that look confident. They are less good at knowing what is in your folder right now: which edits you have not committed, which files Git has never seen, and whether anyone else has pulled your work. A command that is harmless in the AI's imagined repository can wipe out an afternoon of work in yours.

Most Git commands are safe because Git keeps copies. Once something is committed, you can almost always get it back. The dangerous commands are the few that throw away things Git never stored, or that overwrite a shared history other people rely on. Learning to spot those few is far easier than learning all of Git, and it protects you every time you paste a suggestion into a terminal.

The habit is short: before pressing Enter, read each command, ask what it changes, and look at git status to see what is at stake. Open the Areas view on the right while you do it. Every file marked new or changed there is something a careless command could destroy.

git status
git diff
git log --oneline

Which commands can destroy work?

Three commands account for most of the damage people do after following AI advice. Learn their shapes so they stand out when you read a suggestion.

git clean -n
git status -s

git reset --hard moves your branch and overwrites every tracked file to match. Uncommitted edits to tracked files are gone. With a ref such as HEAD~1, it also drops commits from your branch.
git clean -fd deletes every untracked file (-f) and untracked folder (-d). Git never had a copy of those files, so there is nothing to restore.
git push --force (or -f) makes the remote branch match yours, even if that throws away commits on the remote. On a shared repository that deletes other people's work, and their copies then disagree with GitHub.
git checkout -- . and git restore . throw away all unstaged edits to tracked files. They are smaller in scope than reset --hard, and still permanent for those edits.
git branch -D name deletes a branch even if its commits are merged nowhere. The commits linger for a while in the reflog, which is easy to forget about.

What is the AI usually trying to achieve?

When an AI suggests git reset --hard && git clean -fd, the goal is almost always "make my folder match the last commit". That is a reasonable goal when you are sure you need nothing uncommitted. The command pair is the nuclear version of it, and the AI cannot see whether you have a half-written menu page sitting in the folder.

When it suggests git push --force, the goal is usually "make GitHub accept my push". Git rejected the push because the remote has commits you do not have, or because you changed commits that were already pushed. Force tells Git to stop protecting the remote. The calm fix is to understand why Git refused, which the next lesson covers in detail.

Naming the goal helps you pick a gentler command that reaches it. Ask the AI, or yourself, "what state do I want to end up in?" and then choose the smallest command that gets there.

What are the safer alternatives?

Each destructive command has a calmer cousin that reaches the same goal while keeping a way back. Reach for these first, and keep the destructive version for when you have checked and truly want things gone.

git branch backup-before-ai
git stash
git stash list
git stash pop

Instead of reset --hard to get a clean folder, run git stash. Your edits are parked, the folder matches the last commit, and git stash pop brings the edits back if you change your mind.
Instead of reset --hard HEAD~1 to undo a pushed commit, run git revert HEAD. It adds a new commit that undoes the old one, so history stays shared and honest.
Instead of clean -fd, run git clean -n first. It lists what would be deleted and deletes nothing. Commit, move or ignore anything you want to keep, then decide.
Instead of push --force after a rejected push, run git pull to bring in the remote's commits, then git push. If you really must overwrite, --force-with-lease refuses when the remote has commits you have not seen.
Before any risky step, run git branch backup-before-ai. A branch costs nothing and pins your current commit so you can always switch back to it.

A risk ladder for Git commands. Safe to look: status, log, diff, clean -n. Changes history but keeps a way back: commit, stash, revert. Can destroy work: reset --hard, clean -fd, push --force, each with a calmer swap. — Most Git commands sit on the top two rungs, where a way back always exists. When an AI suggestion contains `reset --hard`, `clean -fd` or `--force`, stop and reach for the calmer command beside it.

How do you read a long pasted command?

AI tools love chaining commands with &&. Split the chain at each && and read the parts one at a time. Each part runs only if the one before it succeeded, so a chain like git add . && git commit -m "wip" && git push --force commits everything in the folder, including files you may not want public, and then overwrites GitHub.

For each part, name three things: the command (reset, clean, push), the flags (--hard, -fd, --force), and the target (HEAD~1, origin main, .). The flags carry most of the danger. A bare git reset only unstages; git reset --hard rewrites your folder. A bare git push is refused when it would lose commits; git push --force is not.

If you cannot say what a part does in one plain sentence, do not run it yet. Run the read-only commands (git status, git log --oneline --all, git diff) and ask the AI to explain that one step. A good assistant will happily do that, and you will usually find a gentler option in the explanation.

git log --oneline --all
git diff --staged

How do you check what is at stake before you run it?

Three read-only commands show what a destructive command would cost. git status lists uncommitted edits (lost by reset --hard) and untracked files (lost by clean -fd). git clean -n names the exact files a clean would delete. git log --oneline origin/main shows what is on GitHub, which is what a force push could overwrite.

In the practice repository, git status shows a modified index.html with new Saturday hours and an untracked menu-draft.html. The AI's suggested pair would delete both. Notice that neither file appears in any commit yet, so the reflog cannot rescue them either. Once you commit them, they become part of history and much harder to lose.

A useful rule of thumb: if git status is not clean, commit or stash before you try anything you are unsure of. A clean status means every change lives in a commit or the stash, and Git can bring it back.

git status
git clean -n
git log --oneline origin/main

What if you already ran it?

Stay calm and stop typing destructive commands. What you can recover depends on what was lost. Commits dropped by reset --hard are usually still in the reflog: run git reflog, find the line from before the reset, and run git reset --hard <id> with that short id, or make a branch at it with git branch rescue <id>.

Uncommitted edits to tracked files and untracked files deleted by clean are not in Git at all. Check your editor's undo history or local history panel, and any backup or cloud sync you use. That is the main reason to commit small and often: a commit is the cheapest backup you have.

After a force push that overwrote a teammate's commits, tell them before they pull. Their own clone still has the lost commits, and they can push them back. The practice terminal shows a reflog too, and it accepts names like HEAD@{1} as well as the short id from the left column.

git reflog
git log --oneline -3

How should you prompt an AI about Git?

Give it the facts it cannot see. Paste the output of git status and git log --oneline -5, say whether the branch is shared, and say what you want to end up with: "I want to undo the last commit, it is already on GitHub, and two other people pull from this repo." That last sentence alone steers a decent assistant from reset --hard plus force push to revert.

Ask for the safe version explicitly: "Prefer commands that keep a way back. Warn me before anything that deletes files or rewrites pushed history." Then read what comes back with the same three questions as before: what does it change, what is at stake, and is there a gentler command.

The practice terminal is the safest place to try a command you are unsure about, because nothing here touches your real files. Paste the suggestion, watch the Graph and Areas views, and only then decide whether to run it on your real project.

Field notes

An AI cannot see your uncommitted edits or untracked files.
git reset --hard, git clean -fd and --force can throw work away for good.
Most risky commands have a calmer version that keeps a way back.
Run git status before a risky command to see what it would cost.

Easy to get wrong

The pair deletes uncommitted edits and untracked files with no undo. Stashing parks edits you can bring back, and the dry run shows exactly what a clean would remove.

Rewriting pushed history breaks everyone else's copy and can delete their commits. A revert adds a new commit that undoes the change, so a normal push works.

Each part runs as soon as the previous one succeeds. Running them one by one lets you stop when something looks wrong.

A rejection means the remote has commits you do not. Pulling brings them in so your push adds to history instead of replacing it.

Questions people ask

Is `git reset --hard` ever the right command?

Yes, when you have checked git status, you need nothing uncommitted, and the commits you are dropping were never pushed. For example, throwing away a failed local experiment. Make a backup branch first if you have any doubt.

What does `--force-with-lease` add?

It only overwrites the remote branch if the remote still points where you last saw it. If a teammate pushed in the meantime, it refuses. It is the safer force, though on a shared branch a revert is still kinder.

Can the reflog recover files deleted by `git clean`?

No. The reflog records where branches and HEAD pointed, so it can find lost commits. Untracked files were never in a commit, so Git has nothing to recover.

Why does the AI keep suggesting force push?

It often sees a rejected push message and picks the shortest way to make the error go away. The error is protecting work on the remote. Paste the full message and ask why Git refused instead.

Is `git stash` safe for untracked files?

By default stash only saves tracked files, so a new file stays in the folder untouched. Real Git has git stash -u to include untracked files too; the practice terminal keeps to the default.

Reading AI-suggested Git commands