Something is wrong in a repository an agent touched and you need to know what, now. Find the sentence you would say. Nothing below is new material — it is the shortest path into what the course already proves.
They are almost certainly not gone. Nothing in git deletes a commit — a reset moves a branch pointer, and the commits it moved off are still in the object database with no name leading to them. The reflog records every position HEAD has held, so the name is one command away.
Run this firstgit reflog — before diagnosing, before asking the agent what it did. It often is the whole answer.
The line is git add, not git commit. Staging writes a blob into the object database immediately, so anything you had staged survives even reset --hard and reads back out of git fsck --lost-found. An edit that was never staged existed only in the working tree, and there is nothing behind it to recover.
Run this firstgit fsck --lost-found — dangling blobs are staged content nothing points at any more.
There is more than one kind of conflict, and two of the three put no markers in the file at all — so the path that needs the most thought is often the one that looks untouched. ours and theirs are positional and they invert between a merge and a rebase, which is the single most common way to resolve one backwards.
Run this firstgit status --short first, for the kind. Then git log --oneline -1 HEAD and git log --oneline -1 MERGE_HEAD (or REBASE_HEAD) — read the commits rather than the words.
Conflict markers are ordinary text with no meaning to git. Nothing stops you staging and committing them, and a merge that ends that way succeeds silently — the commit has two parents and looks entirely normal in the log.
Run this firstgit grep -n '^<<<<<<< ' HEAD — it searches the commit rather than your working tree, so it finds them wherever they landed.
The repository squash-merges. A squash puts the branch’s content into main and leaves no link to it, and git branch --merged asks about reachability rather than content — so the branch is unmerged as far as the graph is concerned, and every branch-cleanup tool agrees with it.
Run this firstgit branch --merged main. If branches whose work is plainly in main are listed, the repository squashes.
Usually the squash trap one step later. The branch was squash-merged, someone added a commit to it, and the new pull request carries all the original commits again — so git tries to apply changes to content that already contains them.
Run this firstgit log --oneline main..feature. If it lists commits whose work is already in main, this is it.
Something is reading the branch with a two-dot diff. main..feature compares tip against tip, so it charges a stale branch for everything main gained while it was away. The three-dot form compares against the merge base — what the branch actually did since it left — and that is what a pull request shows.
Run this firstgit diff --stat main...feature (three dots) against git diff --stat main..feature (two). The difference is the answer.
git status never talks to the server. “Up to date” is a statement about origin/main, which is a local file holding a cached answer from the last time you fetched — so it is stale by default, and the push is the first thing in the sequence that actually asks the remote.
Run this firstgit fetch then git status. Fetch touches no branch, no index and no working tree, so it is safe to run in any state.
They are sharing one working tree and one index. A repository has exactly one of each however many branches exist, so git switch rewrites the files under whichever agent was mid-task. Worktrees give each one its own, backed by the same object database.
Run this firstgit worktree add -b agent-x ../wt-x per agent. Then git merge-tree --write-tree <a> <b> to see whether two branches collide, without touching any checkout.
A well-executed rebase produces exactly the history you would have written by hand, so git log alone cannot detect one. The durable tell is the pair of dates: a rebase preserves the author date and rewrites the committer date, so divergence between them is replayed history.
Run this firstgit log --format='%h %an %ad %cn %cd' --date=short. Where the two dates diverge, commits were replayed.