A quick introduction: A friend of mine, Nathan Staines, wanted to pick my brains regarding this mythical beast known as ‘Version Control’. His company had requested its staff to install Dreamweaver for the check-in/check-out feature. Nathan, being wise beyond his years, knew there was an alternative. A better alternative. He pitched me a few questions and I’ve tried my best to answer them.

Why Version Control? – a.k.a Convincing the Boss

“… I was hoping you could point me in the right direction as to how I’d go about convincing them to use something like Git or SVN as a better solution.”

While I’ve sworn off Dreamweaver for life and, hence, don’t know the details of its check-in/check-out feature, I can guarantee that Git/SVN is a better solution. However, they’re also much harder to learn. While I’m personally a fan of Git over SVN, it isn’t for the faint-hearted. You may have seen Andy Clarke’s recent moan and, stubborn though he may be, his views mirrored the cries of many others.

In Nathan’s particular circumstance, I’d recommend SVN. Purely because it has superior Mac GUIs, (Versions, Cornerstone), a shallower learning curve, and is built to run from an externally hosted set of files (repository) making the concept of checking out files and committing changes easier to grasp initially. Windows has TortoiseSVN which integrates straight into menu system. Though, personally, I’m not a fan.

Git does have a similarly good GUI en-route (Git Tower), but it’s currently in Beta, and still trickier to fathom than, say, Versions. Windows has, wait for it… TortoiseGit!, which is also still in development. You can of course use the command line for either, and you’ll see later that for Git, I prefer it.

For either version control system you’ll need a central repository for each project member to access. SVN has Beanstalk and Git has Github. There are others, but I’ve found those two to be the best so far. If you have a capable web developer, or server admin in your midst, they can set up repositories for free on a local server. But often you then can’t access them from outside the building.

I imagine Dreamweaver’s check-in system works on the premise of monitoring files modified in a central location, and simply updates files on each machine when it changes on another, kind of like Dropbox. However, version control typically stores changes, as opposed to the files themselves, except in the case of binary files, such as images. So, at every step of the way, you have a trail of amends made to each file from the moment they were initially checked in, allowing easy reverting to an earlier revision, or grabbing some long lost code fragments previously overwritten and bringing that into your current file. The number and frequency of these changes depends on how often ‘commits’ are made.

The power of version control comes from features like ‘branching’. If you plan on trying something new and quite different, you can create a testing branch and make whatever changes you like, which prevents you from polluting the main branch with broken/untested code that could break the website, allowing you to merge new features later when you’re sure it all works.

“Can you use Git to control an entire website, or is it more useful for smaller projects like themes and frameworks?”

You can put anything you like under version control, but text files use the least space, and allow merging of changes between files. Binary files like images are just versioned as whole files because otherwise the merging process would create some very bizarre and undesired results. In all situations I’ve used version control, it’ll be a repository per whole website, whether that’s a Rails or Django project, or a WordPress site.

Git or SVN?

“Besides the learning curve is there any reason why you’d use SVN over Git or vice-versa… ?”

Being in position of knowing of and having used both, there is no earthly reason I’d use SVN over Git ever again, aside from being required to by companies who have an archive of SVN repositories.

“I want to use either SVN or Git on my own WordPress site hosted by MediaTemple … Is there anything special I need to do?”

If you want to get to grips with version control, Git is actually ideally suited to local development. It’s one of a newer breed of version control systems called a ‘DVCS’, Distributed Version Control System which, by design, does not need a central repository where all the code was kept. It uses that mechanism as an easier way to collaborate on projects.

Working locally, Git is also easier to setup and use than SVN. Particularly if you don’t mind getting your hands dirty in the Terminal/Command Prompt.

Getting Up and Running

Head over to: http://git-scm.com/ and download the latest version of Git. It should be a straightforward install. If you’re not using a Mac, you should just kill yourself now, btw. No reason.

Once that’s done, place your website’s folder structure somewhere easy to maintain and access like the Sites folder in your home directory (Mac), if it’s not already. I think there’s a similar folder on Windows machines. Whip open the Terminal/Command Prompt and find the project you want under version control with a command like

cd ~/Sites/my-project

I think on Windows Vista/7 it would be something like

cd c:/Users/your-profile/sites/my-project

Then run

git init

Boom! Your project is now version controlled. Congratulations. Have a cookie.

It’s advisable to keep the Terminal/Cmd open from now onwards. All you do then is build your website as you would normally. Every so often, flip back to the Terminal/Cmd and, issue:

git add .

(the full stop is important. Tells git to add all changes), then:

git commit -m "description of your changes here"

and get back to building your site. You can think of each commit as a snapshot of your folder structure. The more commits you make, the more snapshots. Though, I wouldn’t worry too much about doing them too often. The ‘add’ and ‘commit’ functions can be rolled into one with the command:

git commit-a -m "description of your changes here"

but by splitting them up, you can perform several adds, or even remove/revert changes before finally committing. Not entirely necessary, but gives you that extra level of flexibility, should you need it.

Here is a good point to note that version control systems need telling when you’ve added or removed files from the folder structure. You’re telling the Git what to and what not to version. Thinking back to the snapshot idea, Git needs to know when files were added/removed so it can keep an accurate ‘state’ of your project. If you’ve ever used or seen Time Machine, it performs a fairly similar visual representation of what version control does, at its simplest. If you removed a CSS file a two weeks ago, and committed that change, to get it back all you’d need to do was look back in the project version history and all ‘states’ from that time and those preceding it will contain that file.

http://gitref.org/ looks to be a nice and concise reference to get you going quickly. Some of the commands you won’t need until you’re collaborating with other people and are using a repository, such as clone, pull and push.

Once you’re familiar with the basic concepts, I’d advise the getting to grips with Git Tower, currently the best GUI available, and stable enough to use. It makes life easier for deleting, reverting to previous versions, branching and merging. But frankly, if you’re using add and commit most of the time, I find the Terminal/Cmd is quicker and easier. But if you’re ever to convince your co-workers of the wonders of Git, it’ll be handy know how to use the GUI.