Essential Git Commands Reference for Developers

Why this matters

A new engineer accidentally git push --force to the team's main branch, wiping yesterday's commits. The recovery is a 30-second git reflog away — if you know it exists. Git is unforgiving in syntax but generous in safety nets, and most developers use 10% of its power because they never built a vocabulary beyond clone, commit, push. A categorized cheatsheet is one of the highest-leverage references a team can keep.

Three real scenarios

Senior Developer

Squash a feature branch's noise commits before merging

git rebase -i main and pick / squash. The reference shows the interactive rebase verbs.

Clean main history

DevOps

Bisect to find which commit broke production

git bisect start good bad, mark each test as good or bad, Git divides until it isolates the culprit.

Root cause in 7 commits

Anyone after a panic

Recover commits seemingly lost to a hard reset

git reflog shows every HEAD movement; git reset --hard <reflog-id> restores.

Disaster averted

Walkthrough — using the reference

Open the Git command reference.

Browse by workflow stage
Setup, daily commits, branch management, sync with remotes, history rewriting, debugging, recovery.
Search for a verb
Type "rebase", "stash", or "cherry-pick"; matching commands surface with explanations.
Copy the canonical invocation
Each entry has a single-line "what you actually type" and a multi-line variant with options.
Read the gotcha note
Many entries warn about --force semantics, pull --rebase vs default merge, etc.
Pin frequently used commands
Bookmark categories (e.g. "history rewriting") for quick retrieval during a stressful moment.

Common everyday workflow

Goal

Start a feature, save WIP, sync with main,
finish, push for PR.

Commands

git checkout -b feature/payment-retry
# work, work, work
git add . && git commit -m "WIP retry logic"
git fetch origin
git rebase origin/main
# fix any conflicts, then:
git push -u origin feature/payment-retry

Recovery after a botched reset

Symptom

You ran `git reset --hard HEAD~5`
and now the last 5 commits seem gone.

Fix

git reflog                       # find the SHA before the reset
git reset --hard <SHA>           # restore HEAD to it

Git command reference grouped by workflow with copy buttons — Workflow categories let new joiners learn Git in the order they actually use it.

Power tips

Use git switch and git restore instead of overloading checkout. switch is for branches; restore is for files. Less ambiguity, fewer mistakes.
--first-parent in git log collapses merge noise and shows mainline-only history.
Set pull.rebase = true to make git pull rebase by default — eliminates "merge merge merge" commits in feature branches.
git commit --amend for fixing the last commit; git rebase -i for fixing older commits. Don't amend after pushing to a shared branch.

Common pitfalls

Common mistake

Force-push wipes a teammate's work

git push --force-with-lease instead of --force aborts if the remote moved since your last fetch. Use it always; reserve --force for branches you know are yours alone.

Common mistake

Accidentally committing secrets

git filter-repo (or BFG Repo-Cleaner) rewrites history to remove the file. Then rotate the leaked secret immediately.

Common mistake

`git rebase main` instead of `git rebase origin/main`

You can rebase against a stale local main. Always git fetch first or rebase against the explicit origin/main ref.

When this is the wrong tool

Visualizing branch graphs — a GUI like Lazygit, GitKraken, or VS Code's Git Graph extension is much faster than git log --graph.
Code review — git diff shows the diff but a proper review tool (GitHub, GitLab, Gerrit) tracks comments and approvals.
Large binary file management — Git LFS or git annex is the right tool, not vanilla Git.

FAQ

What is "fast-forward"?

A fast-forward merge moves the branch pointer along an unbroken line of commits — no merge commit needed. Common when the target branch hasn't moved since your branch started.

For genuinely throwaway WIP. For real work, prefer a wip commit on a temp branch — stashes are easy to forget and lose.

Are reflog entries forever?

No. They expire after 90 days by default for normal entries, 30 days for unreachable ones. After that, only git fsck --lost-found may recover.

Next steps

Pair Git command runs with the Linux command reference for shell utilities (grep, find, awk).
Inspect remote URLs and ports with the URL parser.
Check HTTP error codes from git push (401, 403, 502) against the HTTP status reference.

Why this matters

Three real scenarios

Senior Developer

Squash a feature branch's noise commits before merging

git rebase -i main and pick / squash. The reference shows the interactive rebase verbs.

Clean main history

DevOps

Bisect to find which commit broke production

git bisect start good bad, mark each test as good or bad, Git divides until it isolates the culprit.

Root cause in 7 commits

Anyone after a panic

Recover commits seemingly lost to a hard reset

git reflog shows every HEAD movement; git reset --hard <reflog-id> restores.

Disaster averted

Walkthrough — using the reference

Open the Git command reference.

Browse by workflow stage
Setup, daily commits, branch management, sync with remotes, history rewriting, debugging, recovery.
Search for a verb
Type "rebase", "stash", or "cherry-pick"; matching commands surface with explanations.
Copy the canonical invocation
Each entry has a single-line "what you actually type" and a multi-line variant with options.
Read the gotcha note
Many entries warn about --force semantics, pull --rebase vs default merge, etc.
Pin frequently used commands
Bookmark categories (e.g. "history rewriting") for quick retrieval during a stressful moment.

Common everyday workflow

Goal

Start a feature, save WIP, sync with main,
finish, push for PR.

Commands

git checkout -b feature/payment-retry
# work, work, work
git add . && git commit -m "WIP retry logic"
git fetch origin
git rebase origin/main
# fix any conflicts, then:
git push -u origin feature/payment-retry

Recovery after a botched reset

Symptom

You ran `git reset --hard HEAD~5`
and now the last 5 commits seem gone.

Fix

git reflog                       # find the SHA before the reset
git reset --hard <SHA>           # restore HEAD to it

Power tips

Use git switch and git restore instead of overloading checkout. switch is for branches; restore is for files. Less ambiguity, fewer mistakes.
--first-parent in git log collapses merge noise and shows mainline-only history.
Set pull.rebase = true to make git pull rebase by default — eliminates "merge merge merge" commits in feature branches.
git commit --amend for fixing the last commit; git rebase -i for fixing older commits. Don't amend after pushing to a shared branch.

Common pitfalls

Common mistake

Force-push wipes a teammate's work

git push --force-with-lease instead of --force aborts if the remote moved since your last fetch. Use it always; reserve --force for branches you know are yours alone.

Common mistake

Accidentally committing secrets

git filter-repo (or BFG Repo-Cleaner) rewrites history to remove the file. Then rotate the leaked secret immediately.

Common mistake

`git rebase main` instead of `git rebase origin/main`

You can rebase against a stale local main. Always git fetch first or rebase against the explicit origin/main ref.

When this is the wrong tool

Visualizing branch graphs — a GUI like Lazygit, GitKraken, or VS Code's Git Graph extension is much faster than git log --graph.
Code review — git diff shows the diff but a proper review tool (GitHub, GitLab, Gerrit) tracks comments and approvals.
Large binary file management — Git LFS or git annex is the right tool, not vanilla Git.

FAQ

What is "fast-forward"?

A fast-forward merge moves the branch pointer along an unbroken line of commits — no merge commit needed. Common when the target branch hasn't moved since your branch started.

For genuinely throwaway WIP. For real work, prefer a wip commit on a temp branch — stashes are easy to forget and lose.

Are reflog entries forever?

No. They expire after 90 days by default for normal entries, 30 days for unreachable ones. After that, only git fsck --lost-found may recover.

Next steps

Pair Git command runs with the Linux command reference for shell utilities (grep, find, awk).
Inspect remote URLs and ports with the URL parser.
Check HTTP error codes from git push (401, 403, 502) against the HTTP status reference.