Version control has me stumped

Question

I've been developing websites for a few years now, and I've never had the time or energy to learn about version control. Now, as I start one of the bigger projects I've ever developed, I'm thinking of finally taking that plunge and using this as an opportunity to learn about version control.

I've read a couple of brief descriptions and but I'm still having some trouble grasping the concepts of centralized versus decentralized version control. What are the differences? Advantages/disadvantages?

I'm developing websites on OS X. For the last couple of years I've used a program called Coda to edit my HTML/PHP/CSS/JS and easily upload it to my server with a simple Cmmd + S. I've always kept a 'dev' directory for development, and a 'live' directory for production. Rolling out fixes and new features has always been as easy as updating the 'live' directory with my latest changes in 'dev'. With this project though, I'm expecting to hire some outside designers/developers for specific aspects of the site, which is where I think SCM comes in. Also, for the first time, I'll need a beta version of the site for users to test out new features and provide feedback.

As I understand it, each time I want to make a change, I'll have to fork (?) my own working copy. I don't have my working computer set up as a development server (no MySQL, PHP). How would I use version control using a remote server as the development server? Do I need working directories for each of my developers? How do you use version control in conjunction with MySql or other databases?

Also, I'm on a shared hosting server, so I'll be using a hosted version control system like Beanstalk or Github.

I'm looking for an entire workflow here, it seems like. What do you do?

I know this is a huge question, and I really appreciate everyone's input.

Answer 1

It's not as bad as you think.

You'll learn to love it, because you'll never lose code, you'll be able to keep track of history, and you'll be able to roll back to any version you please.

each time I want to make a change, I'll have to fork (?) my own working copy

This is not true. You can commit changes to a working copy as you go until you're ready to release it. You'll tag and label that version (e.g., "maj.min.svn.build" where major is the major release number, min is the minor release number, svn is the subversion revision number, and build is the automated build number) and merrily go on your way revising the trunk for your next release.

You only need to fork ("create a branch") if you're doing parallel development.

Try Subversion. It's pretty good, even if Linus Torvalds hates it. The "SVN red bean" book is what you should Google and read. Or the Pragmatic Programmer book on version control.

I run CollabNet Subversion on my home machine and routinely check everything into it. It's a great way to practice. The fact that my stuff is safe is an added bonus.

Answer 2

git is one of the easiest things out there, honestly. subversion has a very large mindshare right now, and many of the people who have been using it have trouble learning git (different is hard), but if you don't have experience with either, one is not harder than the other.

The basic model with git is that you do some work and you record a snapshot of your work with a description of what makes it different from the previous snapshot.

It's trivial to see the difference between any two of these snapshots or perhaps "go back in time" and look at the entire state of your project at any prior point. All of these operations are roughly instant, and none require access to any particular server.

Being instant means that you gain a new freedom of experimentation. You will never fear doing some wild and crazy experiment that involves things like removing all of the css files and starting fresh. If it isn't working out quickly, you just toss the work away and go back. But being able to even try this will get you really far.

I like to describe this to newcomers as a well-managed undo coupled with a really awesome backup system. When you push your changes to another repository (e.g. github), you effectively have two copies of every state in your project. It quickly becomes impossible to lose work.

I'd like to emphasize that last point: If you have one computer you work on and you push your snapshots to github, the only way you can lose data is if both github is unavailable (or lost your data somehow) and your computer broke at the same time. If you have two computers you work on, three systems have to break. If you use git to deploy your tree somewhere, four computers have to break.