Every developer uses Git. This site is stored in Git. Yet it's rarely explained from zero. The good news: Git is simple once you understand the mental model — and you only need a handful of commands for 90% of daily work.

What problem does Git solve?

Imagine editing a document and thinking, "this version was better". Without version control, you'd save copies: report_final.doc, report_final_v2.doc, report_FINAL_actually.doc. Chaos.

Git gives you a snapshot of your whole project at every saved point. You can:

The mental model: saves and save-points

The two ideas you need:

Think of commits like save points in a video game. You make them constantly so you can always rewind. The git history is just a chain of commits.

The 5 commands that cover everything

Here's the complete beginner's toolkit: 

git init          # start tracking this folder (do once)
git add .         # stage your changes (choose what to save)
git commit -m "message"   # create a save point
git status        # what's changed? (check constantly)
git log           # see the history of commits

add then commit is the rhythm. First you pick what to save, then you take the snapshot. You'll run git status constantly — it's a safety check, never a chore.

Branching: parallel universes

A branch is a separate line of development — a copy of the project you can experiment in without affecting the main line. 

git branch new-feature   # create a branch
git switch new-feature   # move to it
# ...work and commit here...
git switch main          # go back
git merge new-feature    # bring the work into main

For solo beginners, branches feel optional — and they are, at first. But learning them early makes you comfortable with how real teams work. The golden habit: never commit directly to main when trying something risky.

GitHub: Git in the cloud

GitHub is a hosting service for Git repositories — like Dropbox for your code, plus collaboration tools. The commands that connect them: 

git clone URL        # copy a repo to your computer (start)
git push             # upload your commits
git pull             # download others' commits (or your own from another machine)

push sends your saves to GitHub; pull brings them down. This is exactly how this website deploys — a push triggers GitHub Pages to publish.

Undoing mistakes (the reassuring part)

The best thing about version control: almost nothing is permanent. 

git restore file         # discard uncommitted changes to a file
git reset --hard HEAD    # throw away uncommitted changes entirely
git revert <commit-id>    # undo a past commit safely
git log                  # find any commit-id you need

Messed up? Restore it. Broke everything? Reset. Committed something bad? Revert. Git's whole job is letting you un-do.

Good habits from day one

A typical first session

$ cd ~/myproject
$ git init                    # start tracking
$ git add .
$ git commit -m "Initial version of my app"
$ git branch main             # name the main branch (already set on most setups)
# ... edit some files ...
$ git status                  # "modified: index.html"
$ git add .
$ git commit -m "Add dark mode toggle"
$ git log --oneline           # 2 commits, nice and tidy

Git sounds big, but it's really just: save points (commit), parallel lines (branch), and sync (push/pull). Master those three ideas, and you're using version control like a pro. And the best part — once you start, you'll never want to work without it.