In the games industry, there is no question that Perforce is king. Most studios use it, it’s fast and it works well. I’m pretty comfortable with Perforce, so it was tempting to install a server, especially now that they offer it for free for up to 20 users (it used to be just 2). However I wanted to try something new.
One thing with Perforce is that before you attempt to modify a file, you need to let the server know (files are marked as read-only as a way to help manage this). If you add a new file or delete an old one, you need to let the server know. This is usually fine and you can work with it by integrating Perforce in your tools, like your source code editor. It’s very explicit.
Git works the other way around. You do whatever work you need to do, and when you’re ready to commit it to the server, git will compare your local directory with the repository and automatically detect all the changes you made. This, at least for relatively small projects, is not as slow as it seems. One big advantage is that it’s now possible to work while completely disconnected from the server; you only need a connection when you’re trying to commit. And technically, not even then, as git keeps a local repository, and only syncs it with the global server when you tell it to, so you can make several local commits and only sync to the server after everything works the way you want it to.
The main sticking point with git was finding a visual environment. I would probably get eventually used to the command-line interface but, when all is said and done, I prefer committing my changes with one click. The search turned out a surprising option. Github is not only a popular online git repository, it also provides a polished client. Albeit a bit simple, the interface is clean, and it integrates with the online repository, which makes keeping a backup copy of your files really straightforward.
A nice side effect of going with Github is that it came complete with an issues database. That’s an invaluable tool to keep track of what needs to be done and beats the heck out of a bunch of .txt files or, even worse, a collection of scribbled post-it notes. I’ve used several of these over the years, including Devtrack, Mantis, JIRA, Trac and even Trello. I have a feeling that Github might be a bit too basic for real life work with a moderate team size, but it was just fine for my needs.
The final conclusion, after using it for a couple of months, is that I have to admit I’m only moderately happy with it.
When it works, it works seamlessly. I did run into a recurring problem for a while however, and it was the scariest thing. I would be ready to commit, and the Github tool would tell me that my local repository was corrupt and I had to use the command-line interface to try to fix it. It turns out that you can go down a pretty deep rabbit hole with git, when you run into problems. The internet and patience are your friends and, when everything else fails, you can just clone the online repository and replace your local one (I had to resort to that once or twice).
I couldn’t fully figure out the cause of my woes, but I know it was due to the way I was working between my Windows PC and my MacBook. At first I thought it would be easiest to simply share from my PC the folder I was using to work, and mount it in the Mac. In this way, I could edit files on the PC, where I’m more comfortable, and compile and test the iOS build in the Mac. This is when Github started running into issues. The solution turned out to be like the old joke: if git breaks when I share a folder, I won’t do that. Instead, I installed the Github client in the MacBook and cloned the repository. I still get to share files, although not as easily, and it seems like the issues have gone away.
Finally, a teaser. I added two repositories to Github. One for my project, the other for the throw away prototype I wrote in C# and WPF to test the concept. This one is public, so go ahead and grab it here. You’ll need to compile it, but you can use Visual Studio 2010 Express for that. Enjoy!