Git Command Lookup
Search common Git commands and flags and get a plain-English explanation of what each one does.
What is Git Commands?
A Git command reference you can search by intent. Type what you are trying to do — undo a commit, find a bug, delete merged branches — and it surfaces the command with a plain explanation, the syntax and an example you can copy.
How it works
Every command carries a category, a one-sentence explanation, the general syntax and a working example. Search matches the command name first, then the syntax, explanation and example, with hyphens and underscores treated as spaces so `cherry-pick` and `cherry pick` behave the same. Commands that discard work are marked so the risk is visible before you copy anything.
- Paste or fill in the input. Drop in a commit message, a diff, a package.json, a path list or a set of options. The tool reads it locally — nothing is uploaded and no repository is contacted.
- Adjust the rules to match your project. Every linter here takes its convention from a setting you can change: allowed commit types, header length, target branch length, known branch names. Set them once to what your team actually uses.
- Copy the result. Generated files copy straight to the clipboard or download as a real file with the right name (.gitignore, CODEOWNERS, LICENSE, COMMIT_EDITMSG), and Reset returns every field to its default.
Examples
A commit message that fails CI
"Updated(auth): Fixed the expired-token redirect." is rejected by release automation and reported here with the exact reasons: unknown type, capitalised description, past tense and a trailing period.
A .gitignore that only half works
The Checker shows which rule decides a path — and why `!keep.txt` inside an ignored directory never fires, the mistake that sends people to Stack Overflow.
A dependency bump nobody reviewed
The package.json Diff separates added, removed and changed entries per section, so a caret bump of a runtime dependency does not hide inside a lockfile-sized pull request.
A diff pasted from a code review comment
The Diff Viewer understands several `diff --git` blocks, mode-only changes, renames and binary stubs, and calls out a pasted `--stat` summary instead of rendering an empty box.
Common mistakes
Committing a .gitignore without checking it
Rules look right and behave differently: a pattern containing a slash is anchored to the root, a trailing slash means directories only, and a file inside an ignored directory cannot be re-included. Check the paths that matter before you commit the file.
Rewriting published history
A clean commit history is worth having, but amend, rebase and filter-repo change commit hashes. Only rewrite commits that nobody has pulled; after a rewrite, push with --force-with-lease rather than --force.
Treating a generated file as if it were reviewed
These tools produce a starting point, not a decision. Check the licence text against the canonical source, read the security policy before publishing it, and make sure a CODEOWNERS team actually exists — GitHub silently ignores rules whose owner has no write access.
Putting slow checks in a pre-commit hook
A hook that takes 30 seconds gets bypassed with --no-verify within a week, and then it protects nothing. Keep pre-commit to formatting and linting, move type checks and tests to pre-push or CI.
Frequently asked questions
What is the difference between reset --soft, --mixed and --hard?
They move HEAD to the same place and differ in what happens to your files: `--soft` keeps everything staged, `--mixed` (the default) unstages but keeps the changes, and `--hard` deletes them. Only the last one loses work.
When should I use revert instead of reset?
Whenever the commit has been pushed. `revert` adds a new commit that undoes it and leaves history intact; `reset` rewrites history and forces everyone else to recover with a reflog if they had already pulled.
Is force-pushing ever safe?
On a branch only you use, with `--force-with-lease`, so git refuses if someone else pushed in the meantime. On a shared branch, never — revert instead.