Basic Git Commands Every Software Engineer Should Know

Most engineers learn git by accident — copy a snippet from Stack Overflow, run it, watch what happens. That works for the first few weeks. Then someone force-pushes over your branch, or a merge conflict resolution drops half a feature, and the gaps in your mental model start charging interest.

This post is the floor. Not every git command — just the ones you actually reach for in a normal week, organised by what you’re trying to do. The deeper bits (custom merge drivers, sparse checkouts, sub-trees) you can learn when you need them; you don’t need them yet.

TL;DR

• Git is a content-addressable store + a small graph of commits + three “places” (working tree, index, HEAD).
• Stop guessing at staging — git status and git diff are your two most-used commands by an order of magnitude.
• Branching is cheap, recovering is cheap, history is permanent. git reflog will save you more than any tutorial.
• Use rebase -i to clean up your own branch before merging; never to rewrite shared history.
• Force-push only with --force-with-lease. Plain --force is how teams lose work.
• Set up a handful of aliases (co, st, lg) once; the time saved compounds.

The Mental Model in Three Pieces

Before any commands, three concepts that explain almost everything else.

Almost every command moves data between these three places. git add moves working tree → index. git commit moves index → new commit, advances HEAD. git restore moves backwards. Once you see this, the commands stop feeling random.

Setup and Inspect

The first commands of every project, and the ones you run literally every day.

# Worth doing once on a fresh machine
git config --global core.editor "code --wait"   # or vim, helix, etc.
git config --global core.autocrlf input          # macOS/Linux
git config --global core.autocrlf true           # Windows
git config --global rerere.enabled true          # remember conflict resolutions

git status and git diff are far and away the commands you’ll run most. Don’t try to remember what you changed — ask git.

Stage and Commit

Most “I broke git” stories start here.

# The pattern most engineers want most of the time:
git add -p                  # interactively stage just the relevant hunks
git status                  # confirm what's about to commit
git commit                  # write a real message

git add -p is the single most under-used command. It teaches you to commit one logical change at a time, which makes review easier and history cleaner.

git commit --amend is fine only before you’ve pushed. Once a commit is on the remote, amending it rewrites history — which everyone else now has to deal with.

Branching

Branches are cheap. Make them.

Old commands you’ll see in tutorials: git checkout -b feature/x and git checkout main. They still work, but git switch (for branches) and git restore (for files) split the overloaded checkout into two clear verbs. Prefer them.

# The everyday branch dance
git switch main
git pull                         # update local main
git switch -c feature/login-fix  # branch off the latest
# ...work, commit, push...
git push                         # autoSetupRemote handles the upstream

Merging vs Rebasing

The two ways to integrate one branch into another. Both have their place.

# Merge a feature branch into main
git switch main
git pull
git merge --no-ff feature/login-fix    # explicit merge commit; clear in history

# Rebase YOUR branch onto the latest main (keeps history linear)
git switch feature/login-fix
git fetch origin
git rebase origin/main
# resolve conflicts as they appear, then:
git rebase --continue

If a rebase goes sideways, git rebase --abort puts everything back exactly how it was. Stop using --continue when you’re confused; abort, breathe, try again.

Working with Remotes

Where your code goes to be other people’s problem.

Never use git push --force on a shared branch. It overwrites whatever is there, including commits a teammate just pushed. --force-with-lease is the safety-belted version: it will refuse if the remote tip isn’t what you expect. Use it.

# A safe force-push after rebase
git fetch origin
git rebase origin/main
git push --force-with-lease

Recovering From Mistakes

Almost any git mistake is recoverable as long as the commits weren’t garbage-collected (which takes ~30 days). The trick is git reflog.

# I just rebased and lost everything!
git reflog                              # find the commit hash before the rebase
git reset --hard HEAD@{12}              # restore — your branch is back

# I committed a bug; I need to revert without rewriting history
git revert <bad-commit-hash>
git push

# I'm in the middle of a feature and need to switch branches NOW
git stash
git switch hotfix-branch
# ...later...
git switch -
git stash pop

reset --hard is the most dangerous command in normal use. Always check git status first to confirm you have nothing uncommitted you care about — and remember reflog will still save you for ~30 days even if you forget.

History — Who Did What, When, Why

# Find when a function was deleted
git log -S "calculateInvoice" -- src/billing.ts

# Find the commit that introduced a bug
git bisect start
git bisect bad                  # current HEAD is broken
git bisect good v1.4.2          # this older version works
# git checks out the midpoint; you test, then mark good or bad
git bisect good
git bisect bad
# ...repeat...
git bisect reset                # done; back to where you started

Bisect is magical when the bug appeared “sometime in the last two weeks” and you don’t know where. Even with hundreds of commits, you’ll find it in ≤ log₂(N) steps.

Cleanup — Before You Open the PR

Don’t open a PR with 23 commits called “wip”, “fix”, “actually fix”, “lint”. Clean up first.

# Clean up your branch before requesting review
git rebase -i origin/main         # interactive: squash, reword, reorder
git push --force-with-lease

# The fixup workflow (clean as you go)
git commit -m "Add login form"
# ...later, fixing a bug in the same logical change...
git commit --fixup=HEAD~2
git rebase -i --autosquash HEAD~3

git rebase -i --autosquash is the workflow most professional engineers use: keep messy commits as you work, then squash them into clean logical units before opening the PR.

Things You Should Set Up Once

A handful of aliases pay back the time investment within a week.

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.sw switch
git config --global alias.br branch
git config --global alias.cm "commit -m"
git config --global alias.last "log -1 HEAD"
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.unstage "reset HEAD --"
git config --global alias.amend "commit --amend --no-edit"
git config --global alias.fixup "commit --fixup"
git config --global alias.rb-onto "rebase -i --autosquash"

Now git st, git lg, git fixup HEAD~2, etc.

Two more global settings that earn their keep:

git config --global rerere.enabled true   # remember conflict resolutions; replay them next time
git config --global merge.conflictStyle zdiff3   # 3-way conflict markers — much easier to read

Workflow Cheat Sheet — “I want to…”

Things You Should Almost Never Do

Closing Checklist

When you sit down to work on a branch:

• git status — know the starting state
• Branch off the latest: git switch main && git pull && git switch -c feature/x
• Stage with git add -p to commit one logical change at a time
• git commit with a real message (subject + body, “why” not “what”)
• Before opening the PR: git rebase -i origin/main, squash messy commits, force-with-lease
• On any reset/rebase: git reflog is your safety net for ~30 days
• Delete merged branches locally and on the remote when done

If anything ever goes sideways: git status, then git reflog, then walk back. You almost never need to nuke a clone.

Further Reading

• Pro Git (Chacon & Straub) — free at git-scm.com/book. The canonical reference; chapters 2–7 cover everything in this post in more depth.
• git help <command> and git help --all — the official docs are surprisingly readable.
• Atlassian’s git tutorials — good visualisations for merge vs rebase.
• oh-shit-git.com — concise recovery recipes for every “I broke it” situation.
• Learn Git Branching — interactive sandbox for visualising what each command actually does to the commit graph.

Git’s reputation for being hard comes mostly from learning it command-by-command instead of model-first. Hold the working tree → index → HEAD picture in your head, run git status constantly, trust git reflog to bail you out — and the rest is just vocabulary.