Git Fundamentals

Overview

Git tracks a project's history as a graph of immutable commits, each one a full snapshot of the project plus a pointer back to its parent, rather than storing changes as a linear list of diffs. Getting from a change you've made on disk into that graph goes through three distinct areas: the working directory (the files as you're editing them), the staging area (what you've explicitly told Git to include in the next commit, via git add), and the commit history (what git commit actually records). Almost every command that confuses newcomers - why git status shows a file as both staged and modified, why git restore and git restore --staged do different things, why a rebase "loses" commits that a revert wouldn't - makes sense once that three-stage model is the lens you're looking through, rather than treating Git as a single "save my changes" button.

Quick Reference

The commands below are grouped by what you're trying to do, not an exhaustive reference (see the official Git reference docs for every flag), but the set that covers nearly all day-to-day Git work.

Syntax

git commit -m "<type>: <short summary>"
# e.g.
git commit -m "fix: handle empty response body in retry logic"

git switch -c feature/checkout-retry
# ... make changes, commit ...
git push -u origin feature/checkout-retry

Examples

git switch -c feature/rate-limit
git add lib/rate-limit.ts
git commit -m "feat: add token-bucket rate limiter"
git push -u origin feature/rate-limit

git log --oneline --graph --all

Visual Diagram

Common Mistakes

• Running git add . without checking git status first, accidentally staging generated files, secrets, or unrelated work-in-progress.
• Rebasing a branch that other people have already pulled, which rewrites commit hashes and forces everyone else's local copy to diverge.
• Using git reset --hard to "clean up" without realizing any uncommitted or unstashed work is discarded permanently, not moved anywhere recoverable.
• Committing directly to a shared default branch (main) instead of a feature branch, making it impossible to review or roll back a change independently of everything else.
• Force-pushing (git push --force) to a shared branch to "fix" a mistake, silently overwriting commits a teammate may have already based work on; --force-with-lease at least fails safely if the remote has moved since you last fetched.

Performance

• git status and git add on a very large repository can be slow if the working directory contains many untracked files Git has to scan; a well-maintained .gitignore keeps that scan fast.
• Shallow clones (git clone --depth 1) fetch only the most recent history, dramatically speeding up CI checkouts of large repositories where full history isn't needed.
• Repository size grows with every large binary ever committed, even after the file is deleted, because history is immutable; binaries belong in Git LFS or object storage, not the repository itself.

Best Practices

• Commit small, focused changes with descriptive messages; a commit should represent one logical change, not "end of day checkpoint."
• Use feature branches for anything beyond a trivial fix, and merge or rebase into the default branch through a reviewed pull/merge request.
• Prefer git revert over git reset --hard for undoing anything that has already been pushed and could be shared by others.
• Keep a .gitignore current for build artifacts, dependencies, and local environment files, so git status/git add . only ever surfaces real changes.
• Write commit messages that explain why, not just what - the diff already shows what changed; the message is where the reasoning that won't survive in the code belongs.