Part 1 of this track covered choosing a first language. This part covers the tool that beginners postpone longest and regret postponing most.
Version control is usually taught as a collaboration tool, which makes it sound irrelevant when you are working alone. It is not primarily a collaboration tool. It is an undo history that survives across days, and that is useful from your second week.
The mental model
Think of it as a series of saved game states. At any point you can take a snapshot of your whole project, name it, and continue. Later you can look at any snapshot, compare two of them, or return to one.
Three places exist and understanding the difference resolves most beginner confusion:
- Your working files — what you are editing right now.
- The staging area — the changes you have selected to go into the next snapshot.
- The history — the snapshots you have taken.
Almost every command moves things between these three.
The seven commands
git init— start tracking a project. Once, at the beginning.git status— what has changed and what is staged. Run this constantly; it is the command that tells you where you are.git add .— stage your changes.git commit -m "message"— take the snapshot.git log --oneline— see the history.git diff— see exactly what changed since the last snapshot.git push— send the history to a remote copy.
That covers the large majority of solo work. Branching and merging matter later; ignoring them for now is fine and stops you being overwhelmed.
Writing commit messages
The message is for you in three weeks. “Fixed stuff” is useless then. A useful message says what changed and why:
- Weak: “update”
- Better: “Fix credit weighting so zero-credit courses are excluded”
Write it in the present tense as an instruction — “add”, “fix”, “remove” — and it reads consistently with the messages every tool generates.
Commit more often than feels necessary
A useful rule: commit whenever something works, even partially. Not at the end of the day, not when the feature is finished. The whole value is being able to return to the last point where things worked, and that only exists if you marked it.
Two things to set up once
A .gitignore file. It lists things not to track — dependency folders, build output, anything containing a password or a key. Set it up on day one, because removing a secret from history after the fact is genuinely difficult.
A remote copy. Push to a hosted repository. This is your offsite backup, and it doubles as the portfolio a future employer will look at.
The commands for when things go wrong
git checkout -- filename— discard changes to one file since the last commit.git revert <commit>— undo a past commit by adding a new one that reverses it. Safe, because it adds rather than deletes.git stash— put your current changes aside temporarily and come back to a clean state.
Avoid git reset --hard until you understand it. It is the one command in common use that genuinely destroys work.
The habit
For the next month: git status before you start, commit whenever something works, push at the end of every session. Three small actions, and after four weeks you will have a project history you can read — which is also the moment version control stops feeling like homework and starts feeling like a safety net.
Next in this track
Part 3 covers reading other people’s code, which is what most of a real programming job consists of.