What git is, and why every job assumes it

Every programmer has lived this: project-final.zip, project-final2.zip, project-REAL-final.zip — and then the afternoon where a working program was edited into a broken one and nobody can remember what changed. Version control is the systematic cure: a tool that records snapshots of your project over time, shows exactly what changed between any two, and can restore any of them. Git is that tool — built by the creator of Linux, and so completely dominant that 'version control' and 'git' mean the same thing in every job posting on earth.

Why it is assumed rather than advertised: no team of two or more can function without it (lesson 5 shows why), so employers do not list it any more than they list 'can use a keyboard'. It appears the first hour of the first day: 'clone the repo' is how every job begins. Freelance clients hand you GitHub links; your React course's deployment flowed from a repo; the Cloud & DevOps course's entire CI/CD half stands on git. Learning it takes an honest weekend, and NOT knowing it is one of the fastest ways a junior interview ends early.

Install: git-scm.com, default options (on Windows this includes Git Bash, a terminal worth using for this course). Introduce yourself once — git config --global user.name "Your Name" and user.email — because every snapshot is signed.

First snapshot, in any project folder (your fee tracker from any course is perfect):

git init # start tracking this folder

git add . # stage everything for the snapshot

git commit -m "First version of fee tracker"

That is a COMMIT — a permanent, signed, dated snapshot of every file, stored in a hidden .git folder inside the project. Nothing is sent anywhere (GitHub is lesson 4; git works entirely on your machine). Make a change, run git status — git names what changed — then add and commit again with a message saying what and why. Two commits in, you already have what the zip files never gave you: history you can trust.