Version Control & Git 🕰️

The problem: "final_v2_REAL_final.rs"

You have lived this: an essay saved as final, then final2, then final-ACTUALLY. Now imagine a project with a thousand files and five people editing simultaneously for years. Chaos, unless the history itself is managed by a tool. That tool category is version control, and git (created in 2005 by the creator of Linux) won the category so completely that it is effectively the only one you need.

How git thinks: snapshots 📸

A folder managed by git is called a repository (repo). As you work, you periodically tell git: "this is a moment worth remembering." Git photographs the entire project state. That snapshot is a commit, and it records what changed, when, who did it, and a message saying why. The chain of commits is your project's story, and you can:

• Look at any file as it was at any moment in history.
• See exactly what changed between two moments, line by line (a diff).
• Undo mistakes by returning to a known-good snapshot.
• Experiment fearlessly on a branch (a parallel timeline), then merge it back if the experiment works.

That last one changes how you build. Fear of breaking things is the biggest brake on beginners; git removes the fear. Nothing committed is ever truly lost.

Your five commands

Git has a hundred commands. Daily life uses about five:

git init                       # start tracking this folder (once per project)
git status                     # what changed since the last snapshot?
git add .                      # stage everything changed ("put it on the tray")
git commit -m "Add scoring"    # snapshot the tray, with a message
git log --oneline              # show the story so far

The two-step rhythm (add, then commit) exists so you can choose exactly what goes into each snapshot. Small, well-named commits read like a diary: "Add player struct", "Fix crash on empty input", "Level 2 complete".

GitHub: where repos live together 🌍

Git works entirely on your machine. GitHub (and cousins like GitLab) adds a shared home in the cloud: you push your commits up, teammates pull them down, and strangers can read your open-source code. GitHub is also the world's largest programmer portfolio: when Rustaceans say "check my GitHub," they mean their public work.

Collaboration happens through pull requests (PRs): "here is a branch with my proposed change, please review it." Teammates comment line by line, request tweaks, and finally merge. Nearly every improvement to Rust itself, to Firefox, and to this very site's dependencies arrived as a PR. This site lives at github.com/AES256Afro/The-Rusty-School, and every push automatically republishes rustyschool.com. That workflow (push to deploy) is modern standard practice, and you already own it.

cd ~/rusty-lab
echo "Learning Rust to build fast, safe things." > notes.md
git init
git status                          # see notes.md as untracked
git add .
git commit -m "Start my Rust journey"
git log --oneline                   # one commit: your first!