Git Quick Reference

Analogy categoryAnalogies

This reference groups the Git commands most developers use daily by task rather than alphabetically, because in practice you reach for a command based on what you're trying to accomplish — starting work, saving progress, syncing with others, inspecting history, or recovering from a mistake — not based on its name. It intentionally favors the small set of commands that cover the vast majority of real workflows over an exhaustive listing of every flag Git supports; depth on the handful of operations that matter daily is more useful than shallow coverage of everything.

🏏

Cricket analogy: Like a coaching manual organized by game situation — batting collapse, death overs, spin attack — rather than alphabetically by shot name, because a captain reaches for advice based on what's happening on the field, and mastering the handful of situations that come up every match matters more than knowing every obscure fielding rule.

Starting and configuring

Every new machine or new repository begins with a small set of setup commands: cloning an existing repository, or initializing a new one, plus one-time identity configuration so commits carry the right author information. Global config applies to every repository on the machine unless a repository-local override is set.

🏏

Cricket analogy: Like a new player joining a franchise either by transferring in from another team's full roster (clone) or starting a fresh club from scratch (init), then registering his player ID and jersey name once with the league (global config) unless a specific tournament requires a different registered name (local override).

bash

git clone https://github.com/acme/webapp.git
git init
git config --global user.name "Priya Nair"
git config --global user.email "priya@acme.dev"
git config --global init.defaultBranch main

Saving and inspecting work

The staging area lets you build a commit deliberately rather than committing every change in the working directory at once. 'git status' and 'git diff' are the two commands worth running before nearly every commit — status shows what's changed and staged, diff shows the actual content of unstaged (or, with --staged, staged) changes.

🏏

Cricket analogy: Like a batter deliberately choosing which shots from a net session to include in his highlight reel for the coach (staging), checking the full session summary of what's changed since last review (status), and replaying the actual footage of unselected versus selected shots to see exactly what's different (diff).

bash

git status
git diff                     # unstaged changes
git diff --staged            # staged changes, about to be committed
git add src/api/routes.py    # stage a specific file
git add -p                   # interactively stage hunks within files
git commit -m "fix: handle empty pagination cursor in /orders endpoint"
git log --oneline --graph --decorate -15

Branching and syncing with remotes

Branches are cheap, lightweight pointers, so creating one for every piece of work is the norm rather than the exception. Syncing with a remote means understanding the difference between fetch (download only) and pull (download plus integrate), and pushing a new local branch requires setting an upstream the first time.

🏏

Cricket analogy: Like creating a new practice session for every single drill since sessions cost nothing to set up, checking the league's central archive without altering your own notes (fetch) versus checking and immediately updating your notes to match (pull), and registering your very first solo session with the central archive so future updates know where to sync (setting upstream).

bash

git branch                          # list local branches
git switch -c feature/dark-mode     # create and switch to a new branch
git switch main                     # switch back to an existing branch
git fetch origin                    # download remote changes without merging
git pull origin main                # fetch + merge (or rebase, if configured)
git push -u origin feature/dark-mode  # push and set upstream tracking, first time only
git push                            # subsequent pushes on a tracked branch

'git switch' and 'git restore' were introduced to split the overloaded 'git checkout' command into two clearer, single-purpose commands — switch for changing branches, restore for discarding working-directory changes. Older tutorials and scripts still use 'checkout' for both, which is why you'll see it everywhere even though the newer commands are generally clearer for beginners.

Undoing things

Different mistakes call for different undo commands, and picking the wrong one is the most common source of Git anxiety. The table below (as commands) covers the most frequent 'oh no' moments in rough order of how often they come up.

🏏

Cricket analogy: Like a quick-reference card for a captain's most common in-match mistakes — wrong bowling change, misjudged review, batting order slip — ranked by how often each actually happens, so the most frequent "oh no" moments have the fastest fix at hand.

bash

git restore src/config.py           # discard uncommitted changes to one file
git restore --staged src/config.py  # unstage a file, keep its edits
git commit --amend -m "new message" # fix the most recent commit's message
git revert a1b2c3d                  # safely undo a commit that's already shared
git reset --soft HEAD~1             # undo last commit, keep changes staged
git stash                           # temporarily shelve uncommitted changes
git stash pop                       # reapply the most recently stashed changes
git reflog                          # find a 'lost' commit's SHA after a mistake

Reach for 'git reset --hard' and 'git push --force' only when you are certain no one else depends on the commits being discarded or rewritten — both operate without confirmation, and 'force-with-lease' should be the default over a plain '--force' on any branch other people might also push to.

Group commands by task (start, save, sync, undo) rather than memorizing them alphabetically — it matches how you actually reach for them.
git status and git diff before committing catch mistakes before they become history.
git switch/git restore split the old overloaded git checkout into clearer, single-purpose commands.
git fetch is always safe; git pull additionally merges or rebases into your current branch.
git revert is the safe undo for shared history; git reset --hard and force-push are only safe on history nobody else depends on.
git reflog is the recovery net for 'lost' commits after a bad reset, rebase, or branch deletion.

Practice what you learned

1. What is the practical difference between 'git switch' and the older 'git checkout' for changing branches?

2. When is 'git push -u origin <branch>' needed instead of a plain 'git push'?

3. What does 'git diff --staged' show, as opposed to plain 'git diff'?

4. What is 'git stash' primarily used for?

5. Which command is the correct 'safe undo' for a commit that has already been pushed and pulled by teammates?

Was this page helpful?

Common Git Pitfalls

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Microservices Study Notes

Software Architecture · 30 topics

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Software Engineering Study Notes

Python · 40 topics

Software Engineering

System Design Study Notes

Architecture · 40 topics

Topics covered

#Bash#GitVersionControlStudyNotes#SoftwareEngineering#GitQuickReference#Git#Quick#Reference#Starting#StudyNotes#SkillVeris

Git Quick Reference