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

My only problem with this article is the assumption that programmers love the terminal. Some might, but I absolutely HATE having to type commands into a terminal like it's the 70's, googling for answers rather than having the tool itself teach me. This is why TortoiseSVN is always my first choice. It's nice to see there are GUI-alternatives for Git too but they would have to be on par with TortoiseSVN for me to even pay it a second thought.

##### Share on other sites

You forgot to mention GitExtentions which is another great graphical git client for windows. I haven't tried out TortouiseGit, but GitEx has worked out pretty well for me so far, I never had to use the console once (and I wouldn't eigther, I second Scarabus2 here in that I really despise the command line and all having to do with it).

##### Share on other sites

My only problem with this article is the assumption that programmers love the terminal. Some might, but I absolutely HATE having to type commands into a terminal like it's the 70's, googling for answers rather than having the tool itself teach me. This is why TortoiseSVN is always my first choice. It's nice to see there are GUI-alternatives for Git too but they would have to be on par with TortoiseSVN for me to even pay it a second thought.

Strangely, as a terminal using ludite ;-), I took the opposite message from that part of the article (I thought it was sarcastic). So, it seems that that part of the article would benefit from a bit of a re-write. Perhaps just present it as a section simply on how to use git from the command line without passing judgement one way or the other.

-Josh

##### Share on other sites

One more thing you should add to the Good VCS practices is to keep the commits small and direct.  Too many times I have seen people putting comments like "Fix bug 123", but when you look at the changes, it actually fixed bug 123, bug 234, changed method names, added new methods.

Too many changes in one commit makes it hard to revert, cherry-pick, and analyze.

##### Share on other sites

Also, another awesome GUI git app: SourceTree -- available for Windows and OS X.

Cheers!

##### Share on other sites

I just started hosting my own GitLab server, makes like so much easier when you're on the go.

http://git-scm.com/ Also has a GUI to go with Git

##### Share on other sites

Install http://windows.github.com/ which has direct integration with github, and is easier to use then git for windows I found. Also the clone buttons on github will directly open this application and add the repository to it. It can also deal with non github git connections but it a bit more involved.

Surprised to not see perforce mentioned in this at all because you will likely be touching that when working in a professional environment in the industry. It seems to still be the defacto standard source control software in a lot of places. And perforce is also free for repositories up to 20 users.

##### Share on other sites

My only problem with this article is the assumption that programmers love the terminal. Some might, but I absolutely HATE having to type commands into a terminal like it's the 70's, googling for answers rather than having the tool itself teach me. This is why TortoiseSVN is always my first choice. It's nice to see there are GUI-alternatives for Git too but they would have to be on par with TortoiseSVN for me to even pay it a second thought.

Interestingly, one of the ways that command-line UIs shine is for instruction, because of their simplicity and straight-forwardness. Whenever I have a problem with windows that I need to look up online and solve, I end up with 10 pages of detailed mechanical descriptions of the UI interactions I need to make accompanied by megabytes of screenshots. When I come across similar problems with Linux, where the command-line is the norm, the solution is usually described in one or two pages of simple commands.

Writing similar documentation for a living, I can also say that authoring those GUI-based walkthroughs is a complete pain in the ass -- Those mechanical descriptions of UI interaction are tiresome to write and at the same time completely necessary. All those screenshots, if presented professionally, are painstakingly staged--using descriptive file names for every file that might be shown, having a neutral backgrounds, specific UI settings for fonts, drop-shadows, and a million other things. And poor you if the UI changes in the next version (or next week) because then you get to revisit all of that, including precisely replicating those screenshots if they're affected. Authoring the same for command-line-driven procedures is much, much easier, changes are less-frequent, and updates when they need to happen are far less involved.

Personally, if things can be done on the command-line and don't benefit from a visualization that can't be done reasonably with ascii text, then I prefer command-line. Its just faster. It's also easy to bang up a little script to automate repetetive command-line tasks, while its almost always difficult, brittle, or impossible for GUI interaction (especially *between* tools).

##### Share on other sites

...

It's also easy to bang up a little script to automate repetetive command-line tasks, while its almost always difficult, brittle, or impossible for GUI interaction (especially *between* tools).

Scripting command line tasks is one big advantage command line vs GUI.  You simply can't do it with GUI.  Why would anyone need to script command line tasks?  Build machine, server automations, plenty of example.

##### Share on other sites

Haha "Git != Github" quite embarrassingly this would have helped my understanding when I first got into version control systems. It's a great article and I hope someone finds it useful!

##### Share on other sites

As time passes, I am distinguishing in my mind between version control and source control.  Many people seem to have these two integrated but I would like to have them connected in workflow and not integrated for the sake of better software engineering management. For an indy game developer with strong coding skills then I can see the self-justification for full integration of VS and SC.  Others look more to the future.

I am looking to organization scalability as a major consideration, so clear staging of SC to VS is heavy on my mind.  Git and Perforce are my aim for version control but I would like to see in this article a better source control connection at the front of the workflow pipeline.

[u]Software Engineering Management[/u]

Source Control Stage Repository > Version Control Stage :Git  > Version Control Stage: Perforce

Obvious, everything loops back to management for accountability and documentation purposes, making this more like a cycle of processes than a start to end pipeline, but you get the idea.  This flow allows coders to use either Git or Perforce and establishes the organization for scalability from the start.

Having started in the game development industry as an artist, workflow pipeline stages are often on my mind, as the better art is more efficiently created with a great pipeline. I feel that the readers would be better served in seeing pre-stage and post stage connections to version control with Git in the middle of the pipeline, without going too in depth about pre-stage and post stage.

## Create an account

Register a new account

• 0
• 0
• 25
• 0
• 1

• 13
• 26
• 10
• 11
• 44
×