Git & GitHub: Module 1

Module 1

Copies, backups & the “last good folder” problem

Almost everyone has made a folder called project-final and then project-final-v2 and then project-final-REALLY. That works until you need to answer: what changed between Tuesday and Thursday? or which line broke the layout? Duplicating folders saves a snapshot — it does not save a story.

Why “more copies” isn’t a system

Manual copies are easy to forget, easy to mislabel, and they don’t record intent — only outcome. You might remember which folder is “good,” but a teammate or your future self won’t. For anything you care about — code, writing, a site — you need named checkpoints and a way to compare them.

Backups vs. history

A backup (Time Machine, cloud sync, cloning a disk) protects you when a drive dies or a laptop is stolen. It answers: “can I get a recent copy back?” Version control answers a different question: “how did this file evolve, and can I merge someone else’s work with mine without losing either story?” You want both ideas in your life — backups for disasters, history for craft and collaboration.

Takeaway: Git doesn’t replace a full disk backup. It gives you structured history for text projects and makes it sane to share a codebase with others.

Where we’re going

Next modules introduce version control as an idea, then Git (the tool most of the world uses), then GitHub (a popular place to host repos and collaborate). By the end you’ll see why Coffee tools like Print Punch talk about pushing to GitHub — and how that fits keys and vaults in a later lesson.