I lost two weeks of work before I learned this. You don't have to.
Last week I wrote about the map — four steps to go from "I want to build an app" to actually building one. The third step was Git. And I promised I'd explain it properly.
So here it is. No jargon tour. No history lesson about Linus Torvalds. Just what Git does, why you need it before you write anything you care about, and how to start using it today.
What Git actually is
Git is a save system for your code. That's it.
You know how in a video game you save before a boss fight? So if you die, you don't have to replay the whole level? Git does that for your project.
Every time you reach a point where things are working — or even just a point where you want to remember what you did — you create a save point. Git calls these "commits." You can have hundreds of them. And you can go back to any of them at any time.
I didn't use Git for my first six months of coding. During that time, I broke my app so badly that I couldn't undo it. I lost two weeks of work. Then I did it again three weeks later. Different project, same gut-punch feeling of watching your progress disappear.
After the second time, I spent 20 minutes learning Git. I haven't lost work since.
Why beginners skip it
Because it feels like extra work. You're already struggling to learn Swift or Python or whatever language you picked. Adding another tool on top feels like overhead.
I get that. But Git doesn't slow you down. It makes you faster. Because once you have it, you can experiment freely. You can try something wild, and if it breaks everything, you roll back to your last save point in ten seconds.
Without Git, every experiment is risky. You start second-guessing yourself. "What if I break something?" So you play it safe. You don't try things. That fear quietly slows down your learning more than any tool ever will.
The only five commands you need
There are hundreds of Git commands. You need five. Maybe six if you're feeling adventurous.
git init — Run this once, in your project folder. It tells Git to start watching this folder. You'll never run it again for that project.
git add . — This stages your changes. Think of it as putting files into a box before you seal it. The dot means "everything that changed."
git commit -m "your message" — This seals the box. The message is your note to your future self. "Added login screen" or "Fixed crash on rotate" or "I have no idea why this works but it does." Be honest. Nobody grades these.
git log — Shows you all your save points. Newest first. Each one has your message, a timestamp, and a long ugly ID you can use to go back to it.
git checkout — Go back to an earlier save point. This is the undo button. The one that saves you at 11 PM when you've broken everything and you just want to go back to the version that worked an hour ago.
That's the whole workflow. init once, then add, commit, repeat. Check log when you need to see where you've been. Use checkout when you need to go back.
The 20-minute setup
Here's exactly what to do. Right now, if you have a project.
Open Terminal on your Mac. If you've never opened it before, hit Command + Space and type "Terminal."
Go to your project folder. If your project is on your Desktop in a folder called MyApp, type:
cd ~/Desktop/Document/MyApp
Then:
git init
git add .
git commit -m "first save"
You're done. You have your first save point. Your project is now protected. If you break something tomorrow, you can come back to this exact moment.
Going forward, every time you finish something — a feature, a bug fix, even just an hour of work — run:
git add .
git commit -m "describe what you did"
That's the habit. Two commands. Takes five seconds. Saves you hours of pain.
What about GitHub?
GitHub is not Git. This confuses everyone.
Git lives on your computer. It's local. GitHub is a website where you can upload your Git history so it's backed up online and other people can see it.
You don't need GitHub right now. Git alone is enough. When you're ready to share your code or back it up to the cloud, GitHub is the natural next step. But don't let that stop you from using Git locally today.
One thing at a time.
The commit message that saved me
I want to tell you a quick story about why good commit messages matter.
About three years in, I was working on an app and something broke. A feature that had been working for weeks suddenly wasn't. I opened my git log and scrolled through my commits. Most of them said things like "update" or "fix" or "changes." Useless.
Then I found one that said "added background refresh — works but needs error handling." That was the one. I'd added background refresh, and the error handling I'd skipped was now causing the crash.
I found the bug in two minutes because past-me had written a decent commit message. If that commit had just said "update," I would have spent an hour hunting.
Write messages for future-you. Future-you is tired and confused and just wants to find the problem. Help them out.
I've documented 100 mistakes from 10 years of building apps — the ones I made and the ones I watched junior developers make. Grab the free guide here.
Top comments (0)