Git in 10 Minutes

Every Git command moves files between three places: your working directory (the files you edit), the staging area (a loading dock for the next snapshot), and the repository (the permanent photo album). And a commit is a full snapshot of your project, not a diff. Get these two facts and half of Git's weirdness evaporates.

# the three trees, left to right:
#  working dir  --add-->  staging  --commit-->  repository

git init                # start tracking this folder
git status              # where is everything right now?

Ninety percent of Git life is one three-beat loop. Run git status obsessively — before and after every other command. It's free, it's instant, and it tells you which tree your changes are sitting in. Nobody senior is embarrassed about how often they type it.

git status                     # 1. what changed?
git add main.py                # 2. put it on the loading dock
git add .                      #    (or stage everything below here)
git commit -m "Fix login bug"  # 3. take the snapshot

git log --oneline              # the album, one line per snapshot

A branch is not a copy of your code. It's a sticky note pointing at one commit — 41 bytes. When you commit, the note you're standing on slides forward. That's why creating a branch is instant, and why you should make them freely. HEAD is just "the note you're currently standing on."

git switch -c try-new-parser   # write a note, stand on it
# ...hack away, commit as usual...

git switch main                # jump back — your files change on disk!
git merge try-new-parser       # bring the experiment into main
git branch -d try-new-parser   # throw the note away (commits stay)

GitHub holds a full copy of the repository, nicknamed origin. push sends your new snapshots up; pull brings teammates' snapshots down. That's it. The famous rejection error below scares everyone once — and its fix is one habit: pull before you push.

git clone https://github.com/user/repo.git   # copy down + wire up origin
git pull                       # get the latest before you start
git push                       # publish your commits

git push -u origin my-branch   # first push of a new branch

"How do I undo ___ in Git" is the most-googled question in software. Here's the whole answer, keyed by what you want to undo. One rule first: if the commit was already pushed, use revert (adds an anti-commit) instead of reset (rewrites history under your teammates' feet).

# unstage a file (keep the edits)
git restore --staged secret.txt

# throw away MY EDITS to one file — careful, gone for real
git restore oops.py

# redo the last commit message
git commit --amend -m "Better message"

# undo last commit, KEEP the work (most common wish)
git reset --soft HEAD~1

# undo a commit that's already pushed — the safe public undo
git revert abc1234

A conflict is not an error. It's Git saying: "two people edited the same lines — I'm not going to guess." It then writes both versions into the file with markers and waits. Your job: open the file, keep what should survive, delete the markers, commit. That's the entire ceremony.

CONFLICT (content): Merge conflict in config.py

# inside config.py you'll find:
<<<<<<< HEAD
timeout = 30          # your version
=======
timeout = 60          # their version
>>>>>>> feature-x

# edit to the truth (maybe timeout = 60, maybe something new),
# DELETE all three marker lines, then:
git add config.py
git commit

One day you'll check out an old commit to look at something, and Git will print the scariest paragraph in software. Translation: you're standing on a commit directly instead of on a sticky note. Looking around is completely safe. The only risk is committing new work here — it belongs to no branch, so it's easy to lose.

git switch --detach abc1234    # time-travel to inspect an old snapshot

You are in 'detached HEAD' state. You can look around, make
experimental changes and commit them, and you can discard any
commits you make in this state without impacting any branches...

git switch -                   # done looking — back to where you were

# made commits here you want to KEEP?
git switch -c rescued-work     # slap a sticky note on them — saved

A file named .gitignore lists what Git should pretend doesn't exist: dependencies, build output, .env files with keys in them. Write it in the first ten minutes of every project, because it has a trap: it only affects files Git isn't already tracking.

# .gitignore
node_modules/
.env
*.log
__pycache__/

# "I added .env to .gitignore but Git still tracks it!"
# — it was committed before. Untrack it (keeps the local file):
git rm --cached .env
git commit -m "Stop tracking .env"

The lines everyone googles. Keyed by the sentence in your head.

# "what state is everything in?"
git status

# "save my work"
git add .  &&  git commit -m "message"

# "undo my last commit but keep the work"
git reset --soft HEAD~1

# "this pushed commit was a mistake"
git revert <hash>

# "throw away my edits to this file"
git restore <file>

# "my push was rejected"
git pull   # then push again

# "I'm in a merge from hell, eject"
git merge --abort

# "I deleted something important"
git reflog   # find it, then: git reset --hard HEAD@{n}

# "stash my mess, I need a clean desk for 5 minutes"
git stash    # later: git stash pop

That's the survival kit. The deeper truth about Git: it almost never loses your work — it just files it somewhere you haven't learned to look yet. Every scary message on this page has a two-line exit. You now know all of them.