Up until this year, "version control" for us meant a folder named site-final-v3-actually-final, sitting next to site-final-v2, site-final-v2-old, and at least one folder whose name nobody could fully explain anymore. We finally moved everything into Git, hosted on GitHub, and it's been long overdue.
We didn't need anything elaborate. A master branch that's always deployable, a feature branch per task, and a pull request before merging even though it's just the two of us reviewing each other's work. That last part alone has caught several bugs before they hit a client site, mostly small things, a forgotten debug statement, a hardcoded value that should have been a config setting, that a second set of eyes catches almost automatically during review but that the person who wrote the code is too close to to notice themselves.
What made the switch worth the disruption
The folder-based approach wasn't just inconvenient, it was actively risky. There was no way to see what changed between two versions without opening both and comparing by hand, no way to undo a specific change without undoing everything after it too, and no real record of why a particular change was made months later when we needed to remember. Git's commit history, even used simply, answers all three of those problems essentially for free, as long as we're disciplined about writing commit messages that actually describe what changed and why.
The learning curve was real
Rebasing especially. Merge conflicts the first few times felt genuinely alarming, the kind of red error text that makes you wonder if you've broken something permanently, before we understood that a conflict is just Git asking a question it can't answer on its own, which line should win, rather than something having gone catastrophically wrong. A few tutorials and a printed cheat sheet taped near one of our monitors got us through the first couple of weeks.
Where we landed
At this point neither of us would go back to zip files and folder names as a versioning strategy. It's a small process change that's already paid for the time it took to learn, mostly in the form of bugs caught during review before a client ever saw them, and in the quiet confidence of knowing that any change we've ever made to a project is recoverable if something goes wrong.
Tagging before every deploy
One small addition we made after the first month: tagging the exact commit we deploy to production, something like deploy-2013-06-14, before pushing anything live. It sounds like overkill for two people, but it's saved us at least once already, a client asked us to revert a pricing table change from "whatever was live before Tuesday," and having an actual tagged commit to check out was faster than trying to reconstruct that state from memory or guesswork. It's a single extra command, git tag deploy-YYYY-MM-DD && git push --tags, and it's cheap enough that skipping it would be the harder habit to justify.
GitHub as an accidental backup
We didn't set out to solve backups when we started using GitHub, but it turned out to solve one anyway. Every laptop we own is now a full mirror of the entire project history, remote server included, which means a stolen laptop or a failed hard drive isn't the disaster it would have been a year ago, when a project's only copy might have lived on a single machine and an infrequent backup. We still don't have a formal backup policy beyond that, but knowing the full history lives on GitHub's servers as well as on both of our machines has already quietly removed one source of worry we used to carry around without really thinking about it.