Developer's Guide to Git Cheatsheet: Best Practices and Examples

Git's command surface is enormous, but any given developer's daily workflow really only touches a small, stable subset of it — staging, committing, branching, and syncing with a remote. The mental model that makes the rest click into place is Git's three-tree architecture: the working directory (your actual files on disk), the staging area or "index" (a snapshot of changes you've marked for the next commit via git add), and the repository (the committed history, made up of immutable snapshots referenced by SHA-1 or SHA-256 hashes). Commands like git status and git diff exist specifically to let you inspect the differences between these three trees before committing anything. Branches in Git are lightweight — internally, a branch is nothing more than a movable pointer (a 40-character hash reference stored in a small file under .git/refs/heads/) to a specific commit, which is why creating and switching branches is nearly instantaneous compared to version control systems that copy entire file trees. This also explains why some operations are safe and others are genuinely destructive: git reset --soft only moves the branch pointer and leaves your working directory and staging area untouched, while git reset --hard moves the pointer and overwrites your working directory to match, permanently discarding any uncommitted changes. Understanding which commands merely inspect or rearrange references versus which ones actually delete data is the single most important distinction for using Git confidently without fear of losing work.

[!TIP] Need a quick command reference right now? Try our free, local Git Cheatsheet to search, filter, and copy essential git commands completely offline.

---

Everyday Commands

git status                          # what's changed, staged vs unstaged
git add <file>                      # stage a specific file
git add .                           # stage everything modified/new
git commit -m "message"             # record staged changes
git log --oneline                   # compact commit history
git diff                            # unstaged changes vs last commit
git diff --staged                   # staged changes vs last commit

Branching and Merging

git branch                          # list local branches
git checkout -b feature/new-thing   # create and switch to a new branch
git checkout main                   # switch to an existing branch
git merge feature/new-thing         # merge a branch into the current one
git branch -d feature/new-thing     # delete a branch (only if merged)

Syncing With a Remote

git remote add origin <url>         # link a local repo to a remote
git push origin main                # upload local commits
git pull origin main                # fetch + merge remote changes
git fetch origin                    # download changes without merging

The Commands That Deserve Caution

• git reset --hard HEAD~1 — moves the branch pointer back one commit and discards all working directory changes to match. Uncommitted work is gone; committed work is usually still recoverable via git reflog for a limited time, but don't rely on that.
• git push --force — overwrites remote history to match your local branch, potentially destroying commits a collaborator has already pushed. Prefer git push --force-with-lease, which fails safely if the remote has commits you haven't seen yet.
• git checkout -- <file> — discards uncommitted local changes to a single file with no confirmation and no undo (outside of editor undo history).

---

Conclusion

Git rewards a mental model built around "which of the three trees does this command touch, and does it delete anything" far more than memorizing commands in isolation. A searchable command reference is useful precisely because it lets you confirm a command's exact behavior before running it — especially the handful of commands, like reset --hard and push --force, where a typo or a misremembered flag can genuinely cost you work.