Let me tell you a story about a senior programmer who got hit by a bus.
Don't worry... he's fine. Metaphorically. His company wasn't, though. All of their code lived exclusively on his laptop. When he was out for three weeks recovering, the entire engineering team sat around contemplating their life choices. This is what we call "bus factor" in software development, and it's been a problem since before most of us were born.
I've been writing code since floppy disks were the backup solution. The fancy option back then was burning code to CDs. Then came FTP uploads that took forever, especially that one time I accidentally uploaded every single .obj file from a compiled project. If you don't know what that is, consider yourself lucky. If you do know, you're wincing right now because you've done it too.
Version control used to be a nightmare. Then Git came along.
Git Is Your Safety Net (Not Your Enemy)
Git was created by Linus Torvalds, the "Linux guy." Microsoft bought GitHub, which is still strange to think about. But now it's the standard. You can't avoid it, and honestly, you shouldn't want to. Bitbucket and GitLab (thanks for the swag) exist too, but they're just not as mainstream.
Here's what Git actually does in plain English: it tracks every change you make to your code. It forces you to "commit" (literally the command) to those changes. It stores everything somewhere secure that isn't just your laptop. And it lets multiple people work on the same codebase without everyone's changes turning into a pile of conflict-ridden garbage.
This matters because your laptop will die. Replit will occasionally delete things. AWS will have an outage. GitHub is where your code survives all of that.
The Commit-Often Philosophy
I looked at my Git history from the past 30 days: 294 commits across 19 repositories. About 10 commits per day. Some days hit 30+. Some days are zero, but those are rare.
This isn't because I'm particularly disciplined. It's because I've lost work before, and it sucked. Hours of work, gone, because I thought "I'll commit when I'm done." I wasn't done. I had to rewrite everything from memory.
Now I commit obsessively. When do you commit? Finished a small feature? Commit. Fixed a bug? Commit. Reached a stopping point, working or not? Commit. About to try something risky? Definitely commit. Been more than ten minutes? Commit. Going to lunch? Commit. I'm going to keep saying this until you go commit your code.
Think of commits like video game save points. You want lots of them. You never know when you'll need to get hit by a bus.
Write Commit Messages Your Future Self Won't Hate
Bad commit messages I've seen (and written):
- "Update code"
- "Fix bug"
- "Changes"
- "WIP"
- "asdfasdf"
- "grraaaasdf" (it's late, you're tired, but still no)
These tell you nothing. Six months from now when something breaks, you'll curse past-you for being so lazy.
Good commit messages look like this:
Add user authentication with JWT
Add forgot password link to login page
The format is simple: short summary (under 50 characters), then a longer explanation if needed. The message should explain why you made the change, not just what changed. The code diff shows what changed.
Use imperative mood: "Add feature" not "Added feature." This matches Git's own convention and keeps everything consistent.
Keep Your Branching Strategy Stupid Simple
Most branching strategies you'll read about online are designed for 50+ person teams. You're not that yet. Don't pretend you are.
If you're solo: use main for everything. One branch. Ship features and move on. Only create a feature branch when you're trying something risky and want to preserve main as "known good."
Small team (2-5 people): still mostly use main. Add feature branches when multiple people are working on the same files or when you want someone to review before merging.
Long-lived feature branches are bad juju even on large teams. Keep it simple. Your goal is to ship features, not to impress other programmers with your Git expertise.
GitHub Is Your Backup System
I'll say it again: your laptop will die. GitHub is where your code survives.
What should live in GitHub? Everything that's text. Source code, configuration files (except secrets), database migrations, documentation, deployment scripts, README files. If it's text and it's important, it goes in GitHub.
What should NOT live in GitHub? Secrets (use AWS Secrets Manager), large files like videos or images (use S3), generated files, dependencies like node_modules. And for the love of all that is holy, never commit your .env file with API keys. Remember the fire ants from my security post? Same principle.
Make it a habit: run git status before you stop working. If you see uncommitted changes, commit them. Then push. Every single time.
The Bridge to Production
Here's how this all connects to deployment: GitHub is the bridge between your development environment (usually Replit these days) and production (like AWS or GCP). When you push a tag to GitHub, a GitHub Action triggers and deploys your code automatically. This ensures you never deploy code that isn't in version control, and you can always roll back to a previous version.
If you zoned out there for a minute, just remember that GitHub sits in the middle of everything. Pull it out and the whole pipeline falls apart.
-Sethers
