Git Command Builder

You know what you want to do — squash the last three commits, rebase onto main, push with lease — but you have to look up the flags every time. Pick the operation from a list, fill in the blanks, copy the command. No more `git config --help` rabbit holes.

Covers the operations that bite people: rebase, cherry-pick, reset, stash, tags, remote management, the difference between `git push --force` and `git push --force-with-lease` (which you should pretty much always prefer).

Reads back the command in plain English before you copy it. If something looks wrong, you'll catch it before running it on your work tree.

What you're really doing under the hood is constructing the right invocation of porcelain commands — the user-facing ones like `commit`, `rebase`, `merge`, `reset`, `stash` — with the flags they actually need. The plumbing commands (`update-ref`, `hash-object`, `cat-file`) are not surfaced because almost nobody touches them outside of advanced scripting. Each surfaced operation maps to a specific risk profile: `reset --hard` and `push --force` can lose work; `rebase` rewrites history that others may have pulled; `stash drop` and `branch -D` are immediately destructive. The builder shows the resulting command before you run it precisely so you catch the catastrophic ones.

A worked example: you're trying to bring your feature branch up to date with main using rebase rather than merge. The build is: select 'rebase,' set base to 'main,' confirm 'interactive' if you also want to squash. The output is `git fetch origin main && git rebase origin/main`. If conflicts arise during the rebase, you get instructions for `git rebase --continue` after resolving. If you want to squash the last three commits before pushing, you'd run `git rebase -i HEAD~3`, which opens an editor where you mark commits as 'pick' or 'squash.'

Where it goes wrong most often: rewriting history on a branch others have already pulled. If your teammate has `feature/login` checked out and you rebase your local copy onto a new main, then force-push, your teammate's next `git pull` will produce conflicts that look insane (the same files appearing 'modified' even though no one changed them). The fix is communication and coordination — only rewrite history on branches that are private. The builder prefers `--force-with-lease` over `--force` for any push that follows a history-rewrite operation, which at least catches the case where someone else pushed first.

The reflog is the safety net for almost every 'I just deleted my work' panic. `git reflog` shows where HEAD has been over the last 90 days. If you ran `git reset --hard` and lost commits, those commits still exist as dangling references in the reflog. Find the SHA, then `git reset --hard <sha>` to restore. The only thing you can't recover with reflog is content that was never committed — uncommitted working tree changes that get nuked by reset are genuinely gone.