• # How To Reverse Time - Introduction to Git, Cloud Computing, and Version Control

General and Gameplay Programming

"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 trivial - Version Control

## 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.

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.

Report Article

## User Feedback

You need to be a member in order to leave a review

## Create an account

Register a new account