This post originally available on my devblog.

"Are you telling me I need to rework my entire game from scratch!?"
"If you want to pass, then yes."

This is how a conversation went down with one of my university friends and his professor. My friend had the unfortunate luck of his laptop dying on him, along with all its data, the day his final project is due. Now, while I love my friend, the professor should have failed him. Or it may even be the case that it's the professor who failed, since he didn't teach one very important thing. In the era of cloud computing, there's no excuse for lost data anymore. Having a backup of your data, and even sharing with others has become trivially easy. Perhaps you've heard of Git, or maybe GitHub. People treat it like it's the best thing since sliced bread, and you're left wondering, "What the hell are this things?" If you want a (beginner-friendly) introduction, read on!

But first...

The easy - Cloud file hosting

Cloud hosting services are easy ways to backup your data. All you do is install a program, and you'll have a folder that gets instantly 'synced' with your account. That way, if you lost your local copy, you can always download the data from your account. Neat huh?

These 'free' cloud hosting services are perhaps the most popular:

Dropbox - is the most popular. It starts out with 2 GB, but you can earn up to 20 GB for free quite easily! (It also helps to have connections to a senior VP architect there *grin*)

SkyDrive - Microsoft's Skydrive generously offers 7GB upfront! There's no way to make it bigger though (unless you want to pay).

GoogleDrive - Offers 5 GB upfront but, like Skydrive, you're stuck on that much unless you want to give some cash.

The 'big three' is enough of a list to get you started. Pick one, and when you're ready, go ahead.

The trivial - Version Control

This happens all too often. Let's say you're working on a game and, after hours of work, you may have some of the solid mechanics down. 'Alpha' you call it. You continue working on your game for hours, adding new features and stuff. But compiling it, you realize a drastic mistake with your code. After fiddling with the code a few hours more, you realize how much of a mess your code now is. You bang your head on the wall - if only you could reverse time to when everything worked, to your precious 'Alpha'.

This is where version control comes in. True to its name, a version control system, *ahem* 'controls' your versions so you can easily "reverse time" when you need to. Instead of something akin to cloud file hosting, where your files get synced every time you make an update, here, you save your file every 'version'.

This is a HUGE time saver, since if you want to 'revert' back changes, you could easily do it with a click of a button! (or pedantically, typing a few words)

There are lots of Version Control Systems (VCS) but Git is probably the most relevant right now. There are still people who use SVN though, and knowing two VCS can't hurt right?

The Idea

In its most simple form, here is a Version Control project.

Every little box above is a "version", which we call a "commit". Every "commit" gets saved on what's called the "repository" which is just a fancy word for "the box that contains all your saved data".

Whenever you want to go 'back in time', you "revert" your changes. If we were midway through 'alpha' to 'gold', but we realize there's a mistake, we can easily revert our changes back to 'alpha'.

Collaboration

VCS are more sophisticated than that though, and they are VERY HELPFUL in collaborations, not only because you can revert mistakes of your team, but also because you can have very real boundaries and division of labor.

Let's say your team decides what to work on. We decide that Member A will work on the mechanics of the game. The physics engine is horrendously slow, so we assign Member B, to rework the physics engine.

If we used what we did above, blindly committing changes of your team will get ugly real quickly

What we could do is set up what are called "branches".

In the above, instead of committing in the main line, otherwise called a 'trunk', we create a 'branch', specifically for physics. Note the first commit in the physics branch. There is a 'commit message' aptly named 'buggy physics'. This does not at all affect the main line (containing alpha) and Member A can still work on the mechanics of the game, completely oblivious to the buggy physics.

Member B then manages to get the physics right, and finally 'merges' it. Member A, who at this point did not even see the changes by B, is delighted to see the new, fast physics engine.

Here we see a more complicated VCS, but note that it simply has the concepts above.

That's great, but how do you use it!

SVN

If you're using Windows, TortoiseSVN is an absolutely fantastic tool to work with SVN.

TortoiseSVN, right click menu

Here we see some of the options of Tortoise SVN. They are self explanatory, 'SVN Commit' commits your files, while 'Revert' rolls back changes. 'SVN Update' updates your 'local working copy', so that if your teammates made a new commit, you can see the changes.(your files get synced)

SmartSVN is a good alternative if you're not in Windows.

GIT

First off, Github != Git.

Git, like SVN, is the 'real' Version Control System. Github is a web-based hosting service. Think of it as facebook for Git.

Now that we have that out of the way, let's look at our options for Git. Go ahead and get Git first.

The best option I have found so far for GUI-based git is TortoiseGit, a port of the above TortoiseSVN. Because it's a port, it looks like the above, only that it uses Git.

There is also GitX for all you Mac lovers out there.

So what's github?

Github is a like a social network that uses Git. You can commit your games/files there and people can take a look at it and play with your code, copying your repository and working on it on their own (called forking).

There's a private repository option, but that requires payment.

If you want to have a private git repository for free, try bitbucket.

Good VCS practices

• Keep your commit messages short but punchy.
• Always, always use good commit messages. Tell everyone what you did with your commit, so they can track your changes. There's nothing more scary than 'fix bug' or 'updated game' so you have no idea what was changed.
• Note the side effects of your changes. If you edited the GUI, which in turn changed how the levels work, make sure to note it.
• Branch your code when necessary.
• Test your code before you commit on the main trunk. Seriously.

Git - Something special for real programmers

You ask "Why did you give me Git Gui Options! Tell me how to use git on the terminal!"

If you consider yourself a real programmer, who can't be bothered to use GUI crap, please read my article, Why your games are unfinished, and what to do about it.

If you still want to learn Git through terminal, make sure you're not doing it because you're being an elitist. The above tools are more than enough to get you started on git. Ask yourself 'Will there be any practical gains for me by learning how to use Git through terminal?'.

If the answer to the above is yes, and a real definitive YES, then read on.

I'm not going to lie. I use Git through the terminal and there are real practical gains from doing so. One of which is that you don't get to use GUI crap (heh), and therefore you can be more productive. This is because you minimize clicks. Ideally you would never even need to touch the mouse (some IDEs and even text editors have built in terminals, and you can also Alt-Tab if you need to.)

Here are the very basics of git terminal (some lines taken from git-scm, because they had nice colors):

$ git init

The above initializes your repository in your current directory. This creates an empty git repository.

$ git add *.c
$ git commit -m 'initial project version'

git add *.c adds all the files that has '.c' as an extension in the repository. The commit command accepts a '-m' flag, the string afterwards is your commit message.

Note that git commit will only commit on your local repository. If you're working with a team / using a remote repository, you also need to push your commits to it there.

$ git push origin master

If you want to clone a repository, then use the clone command:

$ git clone git://github.com/schacon/grit.git

You can configure your identity by using:

$ git config --global user.name "Your Name"
$ git config --global user.email "username@domain.com"

And that's the basics of git!

Note: There are other good VCS like Mercurial, but space lacks and this is a good introduction to those who want to get started with VCS.