So I was helping a friend of mine untangle a folder called project_FINAL_v3_ACTUALLYfinal_fixed2.zip last week, and I realized I never actually wrote the post I keep telling people to read. If you've been emailing yourself zip files every time you finish a coding session, or you've got a Dropbox folder full of script_old.py and script_old_old.py, this one's for you. Stop it. Just stop. It's 2011, there's a better way, and it's called Git.
I'm not going to pretend Git is simple. It isn't. The documentation reads like it was written by someone who already understood version control trying to explain it to another person who already understood version control. But the core of it, the part you actually need to get through your day, is like four commands. So let's just do those.
Getting a folder tracked
Open up a terminal, cd into whatever project you're working on, and run:
git init
That's it. That command turns your regular boring folder into a Git repository. It doesn't upload anything anywhere, it doesn't require an account, it doesn't need internet access. It just creates a hidden .git folder that's going to quietly keep track of every change you make from here on out.
Telling Git what you care about
Git doesn't automatically track every file the second you save it. You have to tell it what you want it to pay attention to, using git add:
git add index.html
or, if you're lazy like me most nights at 1am:
git add .
That second one stages everything in the current folder. "Staging" is a weird word for it but think of it like putting stuff in a box before you tape it shut. You're deciding what goes in this particular shipment.
Actually saving the thing
Once it's staged, you commit it:
git commit -m "added the login form, it's ugly but it works"
That message matters more than people think. Six months from now you will not remember what "fixed stuff" meant. I have a commit in an old repo from March that literally just says "ugh" and I have genuinely no idea what I fixed. Write something a stranger could read and understand. Or at least something drunk-you-at-1am could read and understand, since that's probably who wrote it.
Every commit is a snapshot. Not a diff, not a patch, an actual full snapshot of your project at that point in time (Git's smart about storage under the hood, but conceptually just think "snapshot"). That means you can jump back to any commit, ever, and see exactly what your code looked like. Try doing that with a folder called site_v7.
Why this beats the zip file thing
Here's the actual argument, not just "because it's the standard tool" (though it is — pretty much every real project uses it now, GitHub's been growing like crazy this year). The zip file approach fails in specific, annoying ways:
- You have no idea what changed between
v3andv4without opening both and comparing by eye. - You can't easily go back to
v2ifv4turns out to be broken, unless you kept every single zip, which you probably didn't. - If your laptop dies, so does your history. A zip sitting in your Downloads folder isn't a backup strategy, it's a false sense of security.
- You can't collaborate. The second two people touch the same zip you're emailing back and forth going "wait did you get my version," it's over.
With Git, git log shows you every commit you've ever made, in order, with the message you wrote. git diff shows you exactly what changed, line by line, before you even commit it. It sounds small until you're six weeks into a project and something breaks and you need to know which of your forty changes caused it.
One honest complaint before I wrap this up: the terminology in Git is rough for a first-timer. "Staging," "working tree," "HEAD," none of it means what you'd guess. I spent my first week thinking git status was broken because it kept telling me things were "not staged for commit" like it was scolding me. It wasn't broken. I just hadn't run git add yet. Give yourself permission to feel dumb for a few days. Everyone who uses this stuff went through that same week.
I'm not touching branches or GitHub or any of that in this post, that's a whole separate rabbit hole. Just get init, add, and commit into your fingers first. Do it on your next tiny script, even a throwaway one. You'll thank yourself the first time you break something at 11pm and can just quietly undo it instead of digging through your inbox for an attachment from three weeks ago.