Git Command Flow Builder
Select your Git scenario — undo a commit, squash branches, rebase, stash — and get the exact command with safety flags and explanation.
Choose your situation — the tool will output the exact Git commands you need.
Get the exact Git commands for your situation — without memorising flags
You accidentally committed to the wrong branch and now you need to undo it, but you are not sure whether to use reset --soft or --hard, and you definitely do not want to lose anyone else's work. This tool reads your situation, shows you the exact commands, and flags the dangerous ones before you run them.
Step 1: Pick your scenario
The tool presents a grid of common Git situations: undo last commit, undo pushed commit, squash commits, recover deleted branch, stash and switch, and more. Click the card that matches your situation. Each scenario loads a tailored set of commands with variable inputs for branch names, commit counts, and SHA references.
Step 2: Choose your approach
Some scenarios have multiple paths. For example, "undo last commit" offers two options: keep your changes staged (soft reset) or discard them entirely (hard reset). The tool shows sub-option pills for each approach. Click the one you want and the command sequence updates immediately. If you are not sure which to pick, the tool explains what each option does in plain English.
Step 3: Fill in the variables
Type your branch name, commit SHA, or number of commits into the inline input fields. The commands update in real time as you type. If you leave a field blank, the tool uses a placeholder like feature-branch or HEAD~3 so you can see the command structure before committing to specific values.
Step 4: Review and copy
Destructive commands like git reset --hard and git push --force-with-lease are flagged with a red border and a warning block. Commands that rewrite history carry a "Rewrites history" badge. Read the warnings before running anything. Click "Copy all" to grab the full command sequence — comment lines are excluded so you paste only executable commands into your terminal.
How the Git Command Flow Builder generates your commands
Each scenario is a pre-built configuration object
When you click a scenario card, the tool loads a configuration that defines sub-options (when multiple approaches exist), variable input fields (for branch names, SHAs, or counts), command templates with placeholder tokens, and optional warning text. The engine immediately generates the command sequence using default values, so you can see the commands before filling in any custom information. This lets you understand the workflow before committing to specific parameters.
Commands update as you type variables
Command templates use a simple placeholder syntax. When you type into a variable input field, a listener updates the internal state and re-renders all command blocks. The interpolation function replaces every placeholder token with the current value, falling back to a descriptive placeholder if the field is empty. Comment-only lines (starting with #) are rendered in italic muted text without a copy button, keeping the focus on actionable commands.
Dangerous commands are flagged automatically
Destructive commands like git reset --hard, git clean -fd, and git push --force-with-lease are flagged with a red border and a warning block that appears automatically. Scenarios that rewrite history carry a "Rewrites history" badge. The tool is designed so that you cannot accidentally run a destructive command without seeing the warning first. The "Copy all" button excludes comment lines, so you only paste executable commands into your terminal.
The six core Git commands behind most scenarios
Most scenarios use a combination of six fundamental Git commands. git reset moves the HEAD pointer and optionally the index or working tree — --soft keeps changes staged, --mixed unstages them, and --hard discards them. git commit --amend replaces the last commit with a new one. git rebase -i opens an interactive editor where you can squash, reorder, or edit commits. git stash saves uncommitted work to a stack so you can switch contexts. git reflog records every position HEAD has been, letting you recover lost commits. git cherry-pick applies a specific commit from one branch to another.
How the "undo pushed commit" scenario works
When you need to undo a commit that has already been pushed to a shared branch, the tool generates a three-step sequence: first, reset locally to remove the commit; second, amend or remove the offending commit; third, force-push with --force-with-lease. The --force-with-lease flag is safer than --force because it only pushes if nobody else has pushed to the branch since your last fetch. The tool explains this distinction in the warning block so you understand why it matters.
Frequently asked questions
What is the difference between git reset --soft and --hard?
--soft moves HEAD back to the previous commit but keeps all your changes staged in the index, ready to be re-committed. --hard moves HEAD back AND discards all changes in the index and working tree permanently — this is irreversible. --mixed (the default) moves HEAD back and unstages changes but leaves the files modified on disk so you can review them.
Is it safe to force push to a shared branch?
No — force pushing rewrites the remote history, which causes problems for anyone else who has based work on those commits. The safer alternative is git push --force-with-lease, which only force pushes if nobody else has pushed to the branch since you last fetched. Never force push to main or master unless you own the repository and have confirmed no other contributors are working off those commits.
What is git rebase and when should I use it?
Rebase replays your branch's commits on top of another commit (usually the tip of main), producing a linear history without merge commits. Use it before merging a feature branch to incorporate recent changes from main, or interactively with -i to clean up commit history before code review. Avoid rebasing commits that have already been pushed to a shared branch.
How do I recover a commit I accidentally reset away?
Use git reflog to find the commit SHA from before the reset. Reflog records every position HEAD has been, even when commits are no longer reachable from any branch. Once you find the SHA, run git checkout -b recovery-branch <sha> to create a new branch pointing to it. The reflog entries expire after 90 days by default, so act promptly.
What is the difference between git merge and git rebase?
Both integrate changes from one branch into another. Merge creates a new merge commit that joins the histories, preserving the full branching context. Rebase rewrites the feature branch commits as if they were created on top of the latest main, producing a clean linear history. Teams often use rebase for cleaner PR history and merge for long-lived branch integrations.
What does git stash actually save?
By default, git stash saves modifications to tracked files and staged changes, then reverts the working tree to match HEAD. Untracked files are not stashed unless you use git stash -u. Ignored files require git stash -a. Stash entries are stored in a stack-like structure, and you can list them with git stash list to reference specific entries by index.
When should I use cherry-pick instead of merge or rebase?
Cherry-pick applies a single specific commit from one branch to another — it is not a full branch integration strategy. Use it when you need to backport a bugfix from main to a release branch, or when a single commit was made on the wrong branch and needs to be moved. For integrating entire branches, merge or rebase is almost always better.
Why does the tool show a "Rewrites history" badge?
Commands like commit --amend, rebase, and squash change the commit SHA of existing commits. If those commits have already been pushed to a shared remote, collaborators will have a diverged history that requires force pushing or manual reconciliation. The badge is a visual reminder to check whether the branch is shared before executing the command.