Git Command Generator
Describe the task in plain words and get the Git commands for it, filled in with your branch, file and commit names. Every result explains what each command does, and commands that can destroy work come with a clear warning and a safer alternative.
- Runs in your browser
- No sign-up
- Free to use
What these commands do
How to use Git Command Generator
- Choose the task, for example “Undo the last commit, keep my changes”.
- Fill in the names the task needs: branch, file, commit or message.
- Read the explanation and any warning below the commands.
- Copy the commands and run them in your repository.
Git Command Generator features
Task-oriented
Thirty everyday situations, phrased the way you would ask a colleague.
Filled in and quoted
Your branch names, file paths and messages are inserted and quoted for the shell.
Explained
Each command has a comment, and the notes say what happens and what to do when something goes wrong.
Honest about danger
Destructive commands are flagged, and safer forms such as --force-with-lease are used.
Modern Git
Uses git switch and git restore, with the older equivalent mentioned where it matters.
No repository access
Commands are generated as text in your browser; nothing touches your code.
When to use Git Command Generator
- Undoing a commit or a staged file without losing work.
- Cleaning up a feature branch before opening a pull request.
- Getting a rename, a tag or a fork update right the first time.
- Learning what a command found online will really do before running it.
Git Command Generator FAQ
What is the difference between reset, revert and restore?
git restore changes files in your working folder or staging area. git reset moves the branch itself to another commit, which rewrites history. git revert adds a new commit that undoes an earlier one, leaving history intact. For anything already pushed and shared, revert is the safe choice.
Can I undo a hard reset?
Commits removed by a reset can usually be recovered through git reflog, which remembers where the branch pointed for about 90 days. Changes that were never committed cannot be recovered, since Git never stored them.
Why --force-with-lease and not --force?
A force-push overwrites the remote branch with yours. --force-with-lease first checks that the remote is still where you last saw it. If someone pushed in the meantime, the push is refused and their commits survive.
When should I rebase and when should I merge?
Rebase your own unpublished work to keep history linear and easy to read. Merge when integrating finished work into a shared branch. The rule that prevents trouble: do not rebase commits that other people have based work on.
Are these commands safe to copy?
They are standard Git commands, shown exactly as generated. Read the explanation first, and for tasks marked with a warning, make sure you understand what is discarded. When unsure, create a backup branch first with git branch backup.
Do the commands work on Windows?
Yes, in Git Bash, PowerShell and the Command Prompt. Values with spaces are wrapped in single quotes, which Git Bash and PowerShell understand; in the Command Prompt, change them to double quotes.
Three places where your work lives
Most confusion about Git disappears once its three areas are clear. The working tree is the folder of files you edit. The staging area, also called the index, is the list of changes selected for the next commit. The repository is the history of commits. git add moves changes from the working tree to the staging area, git commit moves them into history, and nearly every “undo” command is about moving something back across one of these boundaries.
That explains the family of similar-looking commands. Unstaging a file moves it from the staging area back to “just edited”. Discarding changes overwrites the working tree with the committed version. A soft reset removes a commit from history and leaves its content staged; a hard reset removes it from all three places. Seen this way, the options --soft, --mixed and --hard are simply how far back the undo reaches.
The second important idea is that commits are never edited. Amending, rebasing and squashing all create new commits and move the branch to them. Locally that is harmless. Once the old commits have been pushed and someone else has them, replacing them makes the two histories diverge, and a force-push is required. This is why rewriting commands come with the advice to use them on your own branches only, and why revert exists for shared ones.
Git is forgiving about committed work and unforgiving about uncommitted work. Anything that was committed, even on a deleted branch, can normally be recovered from the reflog. Anything that was only in the working tree is gone when overwritten. Committing often, even with rough messages that are squashed later, is therefore the cheapest insurance available.