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

Answer 1

A few scenarios to illustrate how versioning can help:

You're collaborating with developer Joe on a large project. Most of the code depends on one class. Both of you decide to work on seemingly independent features, but find that that the class requires more member functions. In a non-versioning scenario, Joe and you will get together and decide how to refactor that class to address both your needs, and one of you has to finally write it while the other waits. In the versioning case, both of you can simultaneously modify the class according to your needs in separate branches and merge them- you'd only have something to discuss about if there's a conflict.

You're working on a small project independently. You've developed a stable version and released it. Now, you want to experiment a bit and refactor a lot of things- somewhere down the line, you realize you've taken a wrong turn and wish you could go back a few days (or even a few months for that matter). Versioning history makes this possible.

Team with two lead developers and ten codemonkeys. The lead developers design most of the project's architecture and assign small doable tasks to the junior programmers. They want to periodically review the junior programmers' code. The juniors can periodically push to their respective branches, which the leads will pull and review. The juniors might require a huge number of commits to complete their task. Instead of including all the trivial screw ups in the history of the project, the leads can choose to squash several commits together and then integrate the branch into the mainline. The leads find several bad lines of code- they can blame someone for it, because a versioning system always keeps track of who committed what.

A massive open-source project needs to manage a progress tracker, a bug tracker, mailing lists, community wiki, discussion foums, and ofcourse their versioned code. Launchpad is a fantastic platform that tightly integrates these things together; A commit corresponds to a bug fix. A release can magically be made by tagging. Because the public is not given write access to the main repository, the administrators can accept patches on the mailing list: a versioning system can easily diff the changes between the main project's and the user's code to produce a patch containing the changes.

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

No. You just have to commit.

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?

Doesn't matter. Keep two copies of the repository- one on the development server and one on your machine. Keep them in sync by pushing your changes to the development server's repository.

Do I need working directories for each of my developers?

No, you just need separate branches.

How do you use version control in conjunction with MySql or other databases?

Versioning has nothing to do with databases. You can back up your databases separately.

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

The details depend on the size of your team, your project requirements etc. Otherwise, there's a development branch, a production branch, and several branches for different developers. The developers branch off their own branches to write in independent features, and merge them back. The production branch pulls from the development branch and has tags for various releases. Usually, there are two deployments as well- the development which everyone's constantly testing, and the production for the general public.

Note: I've used distributed versioning system terminology here, but the same questions have equally good answers in the centralized versioning system case.