Git Commands an AI Agent Should Know

The 15-command subset

An AI agent doesn’t need git fluency — it needs fluency on ~15 commands. Anything else is a surface; ask the operator.

1. git status — the read-everything command. Run before any other git action. Habit: every session start.
2. git diff [-- path] — what’s about to be committed. Read before commit.
3. git log --oneline [-N] — recent commits. Use git log --oneline -10 for the last 10.
4. git log --all --oneline --graph — branch structure (lightweight).
5. git add <path> — stage changes. Better than git add -A because selective adds are auditable.
6. git rm <path> — stage deletion. Use instead of deleting files in the worktree then trying to commit.
7. git commit -m "..." — commit staged changes. The body should follow the operator-readable form (see the rules-of-engagement guide).
8. git restore <path> — unstage + revert to HEAD. Reverse of git add.
9. git restore --staged <path> — unstage without reverting.
10. git stash [push/apply/pop] — set aside uncommitted work. Avoid where possible — most stash usage is a sign the agent should have committed first.
11. git branch [-a] — list / create branches. Use -a to include remote-tracking.
12. git checkout <branch> — switch branch. Be careful: it overwrites uncommitted changes in tracked files.
13. git switch <branch> — switch branch (newer, safer; doesn’t touch tracked files).
14. git reset [--soft|--mixed|--hard] — undo commits (with care). --hard loses uncommitted work; never run without explicit operator confirmation.
15. git push [-u origin <branch>] — push commits upstream. Never force-push without operator confirmation.
16. git fetch [origin] [github] — pull remote refs without merging. Cheap, safe.
17. git ls-remote <remote> <ref> — read a SHA from a remote without a local copy. The three-SHA check uses this.

That’s the working set. Everything else (rebase, cherry-pick, reflog) is occasional; ask the operator when you need it.

The failure modes

For each commonly-misused command, the specific failure mode:

• git add -A stages deletions and modifications indiscriminately. The audit trail becomes unclear when the same commit carries unrelated changes. Use git add <path> for selective staging.
• git reset --hard <sha> destroys uncommitted work. There’s no recovery. Never run this without git stash or commit first.
• git checkout <branch> when there are uncommitted tracked changes silently overwrites them. Use git switch instead.
• git push --force rewrites the upstream history. Anyone else who pulled since is now stuck. Avoid unless operator explicitly demands.
• git stash on Windows can mangle line endings. Verify line-ending config (core.autocrlf) before stashing across platforms.
• git log -p without -n dumps the entire history. Use -n N to limit.

The discipline

Three rules an agent’s git history follows:

1. One logical change per commit. A multi-purpose commit (“bumped X, fixed Y, refactored Z”) is hard to revert. The operator’s reverting rule applies per commit.
2. Operator-readable commit messages. Subject + body that read like a changelog. The commit-message pattern from the rules-of-engagement guide is the canonical form.
3. Three-SHA check before push. Local + origin + github must agree. The three-SHA guide covers this.

What the agent does NOT do with git

• The agent doesn’t run git filter-branch or git filter-repo. Those rewrite history destructively. Use only at operator’s explicit request.
• The agent doesn’t git push --mirror. That pushes ALL refs including branches that should stay local.
• The agent doesn’t git config --global without confirming the env. The global config affects every repo; the local config is scoped.
• The agent doesn’t git init a new repo without operator confirmation. The deploy chain assumes the repo exists.

Read-vs-write discipline

Most git commands have a read form and a write form:

• Read-only (no —write semantics): git status, diff, log, ls-files, branch -a, fetch, ls-remote. Safe to run.
• Write (modifies state): add, commit, restore, rm, stash, reset, push. Surface before running on someone else’s branch.

For non-trivial writes, the agent confirms the target (which branch, which remote, which files) before running.

Verification checklist

#	Question	Rule
1	Did I run git status before this action?	Yes
2	Did I run git diff to verify what’s staged?	Yes
3	Are the changes coherent (one logical change per commit)?	Yes
4	Will the commit message format follow the operator-readable form?	Yes
5	Will I push only after the three-SHA check?	Yes

The reflog — the agent’s recovery cord

git reflog is the second-tier safety net behind every command above. It logs every HEAD update — commits, checkouts, reset, merges — and gives the agent a window to recover from mistakes that would otherwise be unrecoverable.

The two common reflog recoveries:

1. git reset --hard <sha> accidentally. The reflog still has the pre-reset HEAD. Run git reflog, find the SHA before the reset, git reset --hard <that-sha>. The “lost” commits come back.
2. git checkout overwriting local changes. Same pattern — reflog has the prior HEAD; switch back. Untracked files persist; tracked-file changes are gone, but you can re-apply via git stash apply if you stashed first.

The reflog is local-only (not pushed), so it survives even when the upstream is fine. It expires after 90 days by default, so a fix needs to happen within that window. The agent should run git reflog --stat once per session if any nontrivial reset has happened — it makes recovery a one-step lookup instead of archaeology.

Sources

• Git reference
• ABS companion: Three-SHA Check Before Pushing
• ABS companion: Search the Codebase Before Fixing Anything

Last verified: 2026-07-14 against the git CLI in active use on the ABS site repo at /srv/abs-site.