Pick the task, get the exact git command — with safety labels and a verify step.
104 of 104 tasks
Where a task has a safer and a riskier command, the safer one is listed first.
git reset --soft HEAD~1Moves the branch back one commit. Everything the commit contained is still in your files and still staged, so you can fix it up and commit again.
git log --oneline -3The undone commit no longer appears at the top (or, on the pushed path, a new revert commit sits above it).
Worth knowing
git reset --soft <commit>Moves the branch back to the chosen commit. Every change from the undone commits stays in your files, staged as one batch.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -5The branch tip is the chosen commit (local path) or new revert commits sit on top (pushed path).
git restore --staged -- <path>Takes the file out of the staging area. The edits stay in the file itself — only the 'ready to commit' mark is removed.
The command keeps its placeholders until the fields above are filled in.
git status --shortThe file now shows as modified but unstaged (an M in the second column).
Before Git 2.23 the same undo was spelled: git reset HEAD <path> — it behaves identically here.
git restore --staged .Empties the staging area for the whole working tree. All edits stay in your files, unstaged.
git status --shortNothing is listed as staged; your edits appear as unstaged modifications.
Before Git 2.23 the same undo was spelled: git reset HEAD
git stash push -- <path>Moves the file's uncommitted changes into a stash and restores the committed version. Get them back any time with git stash pop.
The command keeps its placeholders until the fields above are filled in.
git status --shortThe file no longer appears in the list of modified files.
Before Git 2.23 the discard was spelled: git checkout -- <path>
git stash push -uStashes every tracked edit and every untracked file, leaving a clean working tree. Restore with git stash pop.
git status --shortThe output is empty — the working tree is clean.
git reset --merge ORIG_HEADRewinds the branch to where it was just before the merge (git saved that spot as ORIG_HEAD) while keeping uncommitted edits that don't overlap the merge.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3The merge commit is gone from the top (local path) or a 'Revert' commit sits above it (pushed path).
git merge --abortStops the conflicted merge and puts the branch and your files back exactly as they were before you ran git merge.
git status --shortNo 'unmerged' entries remain; the merge state is gone.
git rebase --abortStops the rebase and returns the branch to the commit it pointed at before the rebase started.
git status --shortThe 'rebase in progress' state is gone and the working tree is back to normal.
git cherry-pick --abortStops the conflicted cherry-pick and restores the branch and files to their state before it began.
git status --shortNo cherry-pick state or unmerged entries remain.
git reflogShows every place your HEAD has pointed recently. Right after a rebase, ORIG_HEAD and the reflog both know the old position.
git log --oneline -5The branch history matches what you had before the rebase.
git reflogThe reflog records every commit your HEAD has pointed at, including ones a hard reset removed from the branch. Copy the id you want back.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3The recovered commit is back at the top of the branch.
Worth knowing
git restore -- <path>Copies the file back out of the last commit into your working tree.
The command keeps its placeholders until the fields above are filled in.
git status --shortThe file exists again and the working tree reports no deletion.
Before Git 2.23 the restore was spelled: git checkout HEAD~1 -- <path>
git restore --staged -- <path>git restore -- <path>git rm staged a deletion and removed the file from disk; these two steps reverse both parts.
The command keeps its placeholders until the fields above are filled in.
git status --shortThe file is back and no deletion is staged.
git clean -ndA dry run: prints every untracked file and folder that a real clean would delete, and touches nothing.
git status --shortNo ?? entries remain (delete) or everything is unchanged (preview).
Worth knowing
git restore --source=<commit> -- <path>Replaces the working copy of the file with the version from the chosen commit. Nothing is committed until you stage and commit it.
The command keeps its placeholders until the fields above are filled in.
git status --shortThe file shows as modified — its content now matches the old commit.
Before Git 2.23 this was spelled: git checkout <commit> -- <path>
git stash push -m <message>Saves your tracked edits into a labelled stash and returns the files to the last commit. Restore with git stash pop.
The command keeps its placeholders until the fields above are filled in.
git stash listYour new stash appears at the top as stash@{0} with the label you gave it.
git stash applyRe-applies the newest stash to your working tree and leaves the stash entry in place as a safety copy.
git status --shortYour stashed edits are back in the file list.
git stash apply <stash>Re-applies the stash you name (as shown by git stash list, e.g. stash@{1}) and keeps the entry in the list.
The command keeps its placeholders until the fields above are filled in.
git status --shortThe chosen stash's edits are back in the file list.
Worth knowing
git stash listShows every stash, newest first, as stash@{0}, stash@{1} and so on.
The command keeps its placeholders until the fields above are filled in.
git stash listThe stash entries you expect are present.
git stash drop <stash>Removes the named entry from the stash list.
The command keeps its placeholders until the fields above are filled in.
git stash listThe deleted entries no longer appear.
git stash push -m <message> -- <path>Stashes only the named file's changes; everything else you were editing stays in place.
The command keeps its placeholders until the fields above are filled in.
git stash listA new stash holding just that file appears at the top.
git fsck --unreachablegit stash store -m <message> <commit>A dropped stash lives on as an unreachable commit until garbage collection. git stash store puts that commit back into the stash list.
The command keeps its placeholders until the fields above are filled in.
git stash listThe recovered stash is back at stash@{0}.
Worth knowing
git branch -m <new-branch>Renames the branch you are on. Commits, history and staged work are untouched.
The command keeps its placeholders until the fields above are filled in.
git branch -vvThe new name is listed (and, on the pushed path, tracks the remote's new name).
git branch -d <branch>Deletes the branch, but only when its commits are already reachable from your current branch — the built-in safety net.
The command keeps its placeholders until the fields above are filled in.
git branch --listThe deleted branch no longer appears in the list.
Worth knowing
git push <remote> --delete <branch>git branch -d <branch>The push removes the branch from the remote for everyone. The companion -d then removes your local copy — it refuses if the branch holds unmerged work, which is your safety net.
The command keeps its placeholders until the fields above are filled in.
git ls-remote --heads <remote> <branch>No output means the branch is gone from the remote.
Worth knowing
git switch -c <branch>Creates the branch at your current commit and switches to it.
The command keeps its placeholders until the fields above are filled in.
git branch -vvThe new branch appears, pointing at the expected commit.
Before Git 2.23 create-and-switch was spelled: git checkout -b <branch>
git switch <branch>Checks out the branch. Uncommitted changes come along if they don't conflict; otherwise git refuses and nothing is lost.
The command keeps its placeholders until the fields above are filled in.
git branch --show-currentPrints the branch you just switched to.
Before Git 2.23 this was spelled: git checkout <branch>
git fetch <remote>git switch <branch>After the fetch, git switch sees exactly one remote with that branch name, creates a local branch from it, and sets up tracking automatically.
The command keeps its placeholders until the fields above are filled in.
git branch -vvThe new local branch is listed and tracks the remote branch.
Before Git 2.23 this was spelled: git checkout --track <remote>/<branch>
git branchLists local branches; the current one is marked with *.
git branch --show-currentConfirms which branch you are on while reading the list.
git push -u <remote> <branch>Publishes the branch and records the tracking link, so future git push and git pull need no arguments.
The command keeps its placeholders until the fields above are filled in.
git branch -vvThe branch now shows its remote counterpart in brackets.
git branch --set-upstream-to=<remote>/<branch>Links your current branch to the named remote branch, so plain git pull and git push know where to go.
The command keeps its placeholders until the fields above are filled in.
git branch -vvYour branch now shows the tracked remote branch in brackets.
git branch --unset-upstreamRemoves the tracking link from your current branch. The branch and the remote branch both stay; only the association goes.
git branch -vvYour branch no longer shows a remote in brackets.
git log --oneline <base>..<compare>The two-dot range means 'commits reachable from the compared branch but not from the base'.
The command keeps its placeholders until the fields above are filled in.
git branch --show-currentComparing never changes your checkout — you are still on the same branch.
git branch --show-currentPrints just the current branch name — empty output means you are on a detached HEAD, not on any branch.
git status --shortRuns clean; the branch name matches what git status reports.
Empty output means detached HEAD: you are on a commit, not a branch. Commits made here need a branch before you switch away — see 'save work from a detached HEAD'.
git branch -c <old-branch> <new-branch>Creates a second branch pointing at the same commit — a cheap safety copy before a risky rewrite.
The command keeps its placeholders until the fields above are filled in.
git branch -vvBoth branches are listed at the same commit.
git switch -c <branch>Uncommitted changes travel with you: creating and switching to the new branch takes them along, and the old branch is left exactly at its last commit.
The command keeps its placeholders until the fields above are filled in.
git branch -vvThe new branch exists and you are on it.
git switch <branch>git cherry-pick <commit>Switches to the target branch and replays the commit there. The original stays where it was — remove it from the wrong branch afterwards with the 'undo the last commit' task.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3The copied commit is at the top of the target branch.
git stash branch <branch>Creates a branch at the commit the stash was made from, applies the stash there, and drops it on success — the cleanest way out when a stash no longer applies to your moved branch.
The command keeps its placeholders until the fields above are filled in.
git status --shortYou are on the new branch with the stashed changes back in your files.
git switch -The dash means 'the branch I was on before this one' — run it again to bounce back.
git branch --show-currentPrints the branch you were on previously.
Before Git 2.23 this was spelled: git checkout -
git switch --detach <tag>Puts your working tree at the tagged commit in detached-HEAD mode — ideal for inspecting or building a release.
The command keeps its placeholders until the fields above are filled in.
git status --shortgit reports a detached HEAD at the tagged commit and a clean tree.
To keep any commits you make here, run: git switch -c <branch> before leaving — see 'save work from a detached HEAD'.
git switch --detach <commit>Moves your working tree to that commit in detached-HEAD mode so you can look around or test without touching any branch.
The command keeps its placeholders until the fields above are filled in.
git status --shortgit reports a detached HEAD at the chosen commit.
Before Git 2.23 this was spelled: git checkout <commit>
To keep any commits you make here, run: git switch -c <branch> before leaving — see 'save work from a detached HEAD'.
git branch -vvLists every local branch with its latest commit, its tracked remote branch in brackets, and how far ahead/behind it is.
git branch --show-currentCross-check the starred row against your current branch.
git branch --sort=-committerdateLists local branches with the most recently committed-to first — handy for finding what you worked on last week.
git branch --show-currentYour current branch should be near the top if you just committed.
git branch --merged <branch>Every branch listed is fully reachable from the named branch, so deleting it loses nothing.
The command keeps its placeholders until the fields above are filled in.
git branch --show-currentListing never changes your checkout.
git refloggit branch <branch> <commit>A deleted branch's commits survive in the reflog; recreating the branch at the old tip brings everything back.
The command keeps its placeholders until the fields above are filled in.
git branch -vvThe branch is back, pointing at the recovered commit.
Worth knowing
git switch -c <branch>Creates a branch right where you are, so the commits you made while detached now have a permanent name and can never be garbage-collected.
The command keeps its placeholders until the fields above are filled in.
git branch --show-currentPrints the new branch — you are no longer detached.
If you already switched away and lost the commits, find them with git reflog and recreate the branch at that id — see 'recover a deleted branch'.
git remote add <remote> <url>Registers the URL under a short name. 'origin' is the convention for your main remote; 'upstream' for the repository you forked from.
The command keeps its placeholders until the fields above are filled in.
git remote -vThe new remote is listed with its fetch and push URLs.
git remote set-url <remote> <url>Points the existing remote at a new URL. History, branches and tracking links all stay as they are.
The command keeps its placeholders until the fields above are filled in.
git remote -vThe remote now shows the new URL.
git remote -vLists every remote with the URLs used for fetching and pushing.
git status --shortListing remotes changes nothing in your working tree.
git remote rename <old-remote> <new-remote>Renames the remote and updates every branch's tracking configuration to match — no branch is left pointing at the old name.
The command keeps its placeholders until the fields above are filled in.
git remote -vOnly the new name appears in the list.
git remote remove <remote>Forgets the remote: its URL, its remote-tracking branches and related settings are removed from this clone. The remote repository itself is untouched.
The command keeps its placeholders until the fields above are filled in.
git remote -vThe removed remote is no longer listed.
git fetch <remote>Downloads new commits and branches from the remote into your remote-tracking snapshot. Your own branches and files never change on a fetch.
The command keeps its placeholders until the fields above are filled in.
git branch -rRemote-tracking branches reflect the remote's current state.
git remote prune --dry-run <remote>Lists every remote-tracking branch whose branch no longer exists on the remote — and removes nothing.
The command keeps its placeholders until the fields above are filled in.
git branch -rStale entries are gone from the remote-tracking list.
git push --force-with-lease <remote> <branch>Replaces the remote branch with your rewritten one, but only if the remote still looks the way your last fetch saw it — if a teammate pushed meanwhile, the push is refused and nothing is lost.
The command keeps its placeholders until the fields above are filled in.
git ls-remote --heads <remote> <branch>The remote branch id now matches your local branch tip.
Worth knowing
git pull --no-rebase <remote> <branch>Fetches, then merges the remote branch into yours, recording a merge commit when both sides have new work.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -5Remote commits are in your history — linearly (rebase) or via a merge commit.
git push <remote> <tag>Publishes a single tag. Ordinary pushes never send tags, which is why yours weren't showing up.
The command keeps its placeholders until the fields above are filled in.
git ls-remote --tags <remote>The pushed tag(s) appear in the remote's tag list.
git push <remote> --delete <tag>git tag -d <tag>Removes the tag from the remote for everyone, then deletes your local copy so a later git push --tags cannot resurrect it by accident.
The command keeps its placeholders until the fields above are filled in.
git ls-remote --tags <remote>The deleted tag no longer appears in the remote's tag list.
git fetch <remote> <branch>Downloads just that branch's new commits. The result is also available as FETCH_HEAD for one-off diffs and merges.
The command keeps its placeholders until the fields above are filled in.
git branch -rThe remote-tracking entry for that branch is up to date.
git clone --branch <branch> --single-branch <url>Clones the repository with only the named branch checked out and tracked — less to download when you need exactly one line of work.
The command keeps its placeholders until the fields above are filled in.
git ls-remote --heads <url>Lists the remote's branches — confirm the one you cloned exists there.
Worth knowing
git clone --depth 1 <url>Clones only the newest commit of each branch instead of the whole history — much faster for big repositories when you just need the current files.
The command keeps its placeholders until the fields above are filled in.
git ls-remote --heads <url>The remote is reachable; your clone holds its latest commit.
Worth knowing
git fetch --unshallowDownloads the history your shallow clone skipped, turning it into a complete clone with full log, blame and bisect.
git rev-list --count HEADThe commit count now reflects the full history, not just the shallow slice.
git fetch <upstream>git switch <branch>git merge <upstream>/<branch>git push <remote> <branch>Fetches the original repository, merges its branch into yours, and pushes the result to your fork — the standard fork-maintenance loop.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -5Upstream's latest commits now appear in your branch history.
Worth knowing
git ls-remote --heads <remote>Asks the remote directly for its branches — live data, unlike git branch -r which shows your last-fetched snapshot.
The command keeps its placeholders until the fields above are filled in.
git remote -vConfirms which remote you just queried.
git push <remote> --allPublishes every local branch to the remote in one command — useful when moving a repository to a new home.
The command keeps its placeholders until the fields above are filled in.
git ls-remote --heads <remote>Every local branch now appears on the remote.
git commit --amend -m <message>Replaces the last commit with an identical one carrying the new message. Staged changes, if any, are folded in too.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3The top commit shows the new message.
Worth knowing
git add -- <path>git commit --amend --no-editStages the file and folds it into the last commit. --no-edit keeps the existing message.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3Still one commit at the top — now containing the forgotten file.
git commit --amend --no-edit --author=<author>Rewrites the last commit with the author you give as 'Name <email>', keeping the message and content unchanged.
The command keeps its placeholders until the fields above are filled in.
git log -1 --format=%an%x20%aePrints the top commit's author name and email — now the corrected identity.
Worth knowing
git reset --soft <commit>git commit -m <message>Rewinds to the chosen commit with every later change still staged, then records them as a single new commit — a squash with no interactive rebase.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3One combined commit now sits where the several used to be.
git revert --no-edit <commit>Creates a new commit that applies the exact inverse of the chosen commit. History is preserved — this is the safe undo for anything already shared.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3A Revert commit appears (or git status shows the staged reversal).
git revert -m 1 --no-edit <merge-commit>Reverting a merge needs to know which side to keep: -m 1 keeps the branch you were on when you merged and backs out everything the merged branch brought in.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3A Revert commit sits above the merge; the merged changes are gone from the files.
git cherry-pick <commit>Replays the chosen commit onto your current branch, keeping its message and authorship.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3The picked commit is on top (or its changes are staged, on the review path).
git cherry-pick <start-commit>..<end-commit>Replays every commit after the start (exclusive) up to the end (inclusive), oldest first, each as its own commit.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -5The picked commits appear on top in their original order.
git rm --cached -- <path>git commit --amend --no-editRemoves the file from the last commit only — enough when the mistake was just committed and never existed before. Add it to .gitignore so it can't come back.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -- <path>No commits mention the file any more (last-commit path: the newest commit doesn't).
Worth knowing
git rebase --onto <commit>^ <commit>Replays every commit after the doomed one onto its parent — the commit disappears and the rest keep their order. If a later commit depended on it, the rebase pauses with a conflict.
The command keeps its placeholders until the fields above are filled in.
git log --oneline -5The dropped commit no longer appears in the history.
git reset --mixed HEAD~1git add -- <path>git commit -m <message>Unpacks the last commit into your working tree, then lets you re-commit it in as many pieces as you like.
The command keeps its placeholders until the fields above are filled in.
git status --shortAfter the first piece is committed, the remaining changes are still listed, ready for the next commit.
git log --oneline -20The last 20 commits, one line each — id and title.
git status --shortViewing history never changes anything.
git log --oneline -- <path>Lists every commit that changed the file, newest first.
The command keeps its placeholders until the fields above are filled in.
git status --shortViewing history never changes anything.
git blame -- <path>Prints the file with, on every line, the commit, author and date that last touched it.
The command keeps its placeholders until the fields above are filled in.
git status --shortBlame is read-only.
git log --oneline --diff-filter=D -- <path>Lists only commits that DELETED the path — the top result is when it disappeared. Restore it from that commit's parent with the 'recover a deleted file' task.
The command keeps its placeholders until the fields above are filled in.
git status --shortSearching history never changes anything.
git log --oneline --grep=<text>Lists commits whose message matches the text (a regular expression).
The command keeps its placeholders until the fields above are filled in.
git status --shortSearching history never changes anything.
git log --oneline -S <text>The 'pickaxe' search: lists commits where the number of occurrences of the text changed — i.e. where it was added or removed.
The command keeps its placeholders until the fields above are filled in.
git status --shortSearching history never changes anything.
git show <commit>Prints the commit's metadata, message and full diff.
The command keeps its placeholders until the fields above are filled in.
git status --shortShowing a commit never changes anything.
git diff <base> <compare>Shows what changed going from the older commit to the newer one.
The command keeps its placeholders until the fields above are filled in.
git status --shortDiffing never changes anything.
git tag -a <tag> -m <message>Creates an annotated tag at your current commit — it records who tagged, when and why, which is what release tooling expects.
The command keeps its placeholders until the fields above are filled in.
git tag --listThe new tag appears in the list.
Worth knowing
git tag -d <tag>Removes the tag from your clone only. If it was pushed, remove it from the remote too with the 'delete a tag from a remote' task.
The command keeps its placeholders until the fields above are filled in.
git tag --listThe tag no longer appears.
git rev-list --count HEADPrints how many commits are reachable from your current position.
git log --oneline -3Sanity-check the newest commits against the count.
git log --oneline --author=<text>Lists commits whose author matches the pattern — a name fragment or an email works.
The command keeps its placeholders until the fields above are filled in.
git status --shortSearching history never changes anything.
git show <commit>:<path>Prints the file's full content exactly as that commit recorded it, without touching your working copy.
The command keeps its placeholders until the fields above are filled in.
git status --shortViewing an old version never changes anything.
Worth knowing
git reset --soft HEAD@{1}HEAD@{1} is where your branch pointed just before the amend — resetting softly there restores the original commit while keeping the amend's extra changes staged.
git log --oneline -3The top commit is the pre-amend one again.
git reset --soft HEAD~1Removes the cherry-picked commit from the tip while keeping its changes staged (assumes it is the newest commit).
The command keeps its placeholders until the fields above are filled in.
git log --oneline -3The cherry-picked commit is gone (local) or a revert sits above it (pushed).
git config user.name <your-name>git config user.email <your-email>Stores the identity in this repository's .git/config — it wins over the global setting, which is how you keep a work identity in work repos.
The command keeps its placeholders until the fields above are filled in.
git config --get user.emailPrints the email that new commits will record.
Worth knowing
git config --list --show-originPrints every effective setting together with the file it came from — the fastest way to see which scope is winning.
The command keeps its placeholders until the fields above are filled in.
git status --shortReading configuration changes nothing.
git config --global init.defaultBranch <branch>Every future git init on this machine starts on this branch name. Existing repositories are not touched.
The command keeps its placeholders until the fields above are filled in.
git config --get init.defaultBranchPrints the name new repositories will start with.
Worth knowing
git config --global core.editor <editor>The command git launches for commit messages and similar prompts. For VS Code use 'code --wait' — the --wait keeps git waiting until you close the tab.
The command keeps its placeholders until the fields above are filled in.
git config --get core.editorPrints the editor command git will launch.
git config --global pull.rebase trueEvery git pull now rebases your local commits on top of the fetched branch — the setting that silences the 'divergent branches' hint with linear history.
git config --get pull.rebasePrints true (rebase) or false (merge).
git config --global alias.<shortcut> <expansion>After this, git <shortcut> runs the expansion — e.g. alias.st set to 'status --short' makes git st a two-key status.
The command keeps its placeholders until the fields above are filled in.
git config --get-regexp aliasLists your aliases, including the new one.
git config core.fileMode falseThis repository stops treating executable-bit changes as modifications — the usual fix when a mounted drive or another OS flips permissions on everything.
git config --get core.fileModePrints false — mode-only diffs are now ignored here.
Worth knowing
git config --global core.autocrlf inputFiles are committed with LF endings and checked out untouched — the standard setting on macOS and Linux.
git config --get core.autocrlfPrints input (macOS/Linux) or true (Windows).
Worth knowing
git config --global credential.helper cacheGit remembers credentials in memory for 15 minutes by default — nothing is ever written to disk.
git config --get credential.helperPrints the helper git will use.
git rm --cached -- <path>git commit -m <message>.gitignore only affects UNtracked files — this is the missing step. The file leaves version control at this commit but stays in your working tree; add it to .gitignore so it never comes back.
The command keeps its placeholders until the fields above are filled in.
git status --shortThe file now shows as untracked (??) — or not at all once ignored.
git check-ignore -v -- <path>Prints the exact .gitignore file, line number and pattern that matches the path — no more hunting through nested ignore files.
The command keeps its placeholders until the fields above are filled in.
git status --shortChecking ignore rules changes nothing.
Worth knowing
git config --global push.autoSetupRemote trueFrom now on, a plain git push on a branch with no upstream publishes it and sets up tracking automatically — the 'fatal: the current branch has no upstream' error disappears (Git 2.37+).
git config --get push.autoSetupRemotePrints true — new branches now push without ceremony.
git config --global color.ui autoColors status, diff, branch and log output when writing to a terminal, and stays plain when piping to files or other commands.
git config --get color.uiPrints auto.
The search looks at task names, plain-English intents and the git commands themselves. Try one verb — undo, delete, rename, unstage — or clear the search to see all five groups again.
Do it offline:$ git log --oneline -3
Undo a commit is only the front door: this page holds 104 git tasks across undo & recover, branches, remotes, history and config. Open one, answer outcome questions — keep my changes, or throw them away — instead of recalling flags, then copy the exact command: destructive variants carry a labelled warning, and every task ends with a line that checks the result. Names you type are substituted right on this page.
Each task is a small decision tree stored as data: every combination of its toggle answers maps to a command sequence enumerated ahead of time, so switching an answer swaps in a different pre-built variant rather than editing a string. Within a toggle the safer variant is listed before the dangerous one, and each destructive variant carries its own warning note.
The directory is verified by execution, not proofreading: all 163 command variants run against a real repository — a scratch working copy with a local bare repository standing in for origin. Every line must exit zero, the task's verify command must exit zero, and the outcome is then confirmed with plumbing such as rev-parse, status --porcelain and ls-remote. The date below is that run's date.
Name checking mirrors git check-ref-format. A branch or remote name is refused for a space, a control character, any of ~ ^ : ? * [ \, the sequences .., @{ and //, a segment starting with a dot or ending in .lock, or a leading dash — each with the position that failed. Values that pass but would still confuse a shell are quoted on substitution, so an apostrophe in a commit message never breaks the copied line.
Commands target the spellings git has used since 2.23, when restore and switch took over the undo duties of checkout; where an older spelling differs, the task carries it in a separate note. Tasks that rewrite history fork on one question — has this been pushed? Local-only answers use reset and amend; pushed answers build a revert, which undoes by adding a commit instead of rewriting shared history.
undo-last-commit · keep my changes (staged) · not pushedgit reset --soft HEAD~1The directory's default variant. The branch pointer moves back one commit while its changes stay staged, ready to fix and recommit; git log --oneline -3 then shows the undone commit no longer on top. The old tip remains in the reflog.
delete-remote-branch · remote origin · branch feature/xgit push origin --delete feature/x
git branch -d feature/xTwo ordered lines: the push removes feature/x from the remote for everyone, then the companion -d removes your local copy — and refuses if it still holds unmerged work. Empty output from the verify line means the remote branch is gone.
rename-branch · the one I'm on · also on the remotegit branch -m feature/login
git push -u origin feature/login
git push origin --delete feautre/loginRenaming away a typo while standing on the branch. The order matters: rename locally, publish the new name with tracking set (-u), and only then delete the old name — the branch is never absent from the remote.
Every example on this page is executed against the same engine that powers the tool, on every build.
Checking out a tag or a raw commit puts you on a commit instead of a branch, and git branch --show-current prints nothing. Commits made there need a branch before you switch away, so the affected tasks carry a note pointing at the save-my-work step: git switch -c with a new name.
Undo tasks fork on whether the commit left your machine. Rewriting locally is routine; rewriting a pushed branch makes it diverge from the remote for everyone tracking it. The pushed paths therefore build revert commands, and local-only is a visible pre-selected answer, never a hidden assumption.
git restore and git switch arrived in 2.23 (August 2019). Older installations spell the same operations with reset and checkout — git reset HEAD <path> to unstage, git checkout -- <path> to discard — and affected tasks show the older line in a per-task note. The behaviour is identical.
The lease compares the remote branch against your remote-tracking snapshot and refuses the push when the remote has commits you haven't fetched. Fetching renews that lease, so a bare fetch-then-push waves through whatever just arrived — inspect the new commits (git log main..origin/main) before pushing, and remember that background fetches from IDEs renew the lease the same way.
Deleting a local branch — even force-deleting — removes a label; the commits stay in your reflog for at least 30 days by default. Remotes usually keep no reflog, so deleting a remote branch is the step that actually strands work. That task's warning includes the push syntax that restores it from a commit id.
A space at position 3 can't be used in a branch name — git ref names never contain spaces, control characters or ~ ^ : ? * [ \.A branch name can't contain ".." — found at position 8; remove or separate those characters.A branch name can't start with "-" — git would read it as a command option; start with a letter or digit instead."HEAD" is reserved by git and can't be used as a branch name — pick another name.A space at position 5 can't be used in a revision — use a commit hash, a branch or tag name, or a form like HEAD~2.This value is 257 characters long — the limit for a command parameter is 256 characters; shorten it before building the command.Answer yes on the pushed toggle and the task builds a revert: git revert --no-edit HEAD adds a new commit reversing the last one, so shared history is never rewritten and teammates simply pull the reverting commit. Resetting instead would make your branch diverge from the remote.
No. It moves the branch pointer back one commit and leaves your files and staging area untouched — the undone commit's changes sit staged, ready to commit again. Deletion enters only with --hard, which sits behind an explicit throw-the-changes-away answer and wears the destructive label.
--force replaces the remote branch unconditionally, including commits you have never seen; --force-with-lease refuses the push when the remote no longer matches your last fetch, failing instead of overwriting a teammate's work. The force-push task lists the lease form first.
git restore --staged -- <path> takes the file out of the staging area and touches nothing in your working copy. Before Git 2.23 the identical operation was git reset HEAD <path>. Discarding the edits themselves is a different task here, and its discard variant is labelled destructive.
Commits dropped by a reset or branch deletion stay in your reflog — by default about 90 days for reachable entries, 30 for unreachable ones — until garbage collection prunes them; git reflog lists them for recovery. Remotes are the exception: a deleted remote branch usually leaves no reflog at all.
Ref names follow git check-ref-format: no spaces or control characters, none of ~ ^ : ? * [ \, no .., @{ or //, no segment starting with a dot or ending in .lock, no leading dash. The name fields on this page apply the same rules and point at the exact character that fails.
Yes — the undo-merge task forks the usual way. Local-only uses git reset --merge ORIG_HEAD to step back to the pre-merge state; a pushed merge is reversed with git revert -m 1, where -m 1 names the mainline parent a two-parent commit cannot infer on its own.