I’ve always loved programming and hated source control. Source control is about baby-sitting your code instead of actually producing it. It’s like time management instead of actual work. Complicated and boring process that requires discipline, attention to and knowledge of things unrelated to the real project you are making. That has always stopped me from even considering source control. Believe it or not, but for seven years I’ve been developing my blogging system, E2, without source control (still, it’s the best blogging system in the world).
I am also not a big fan of the command line. I know how to spell “sudo apachectl restart”, and that’s pretty much sums it up. So all that svn / git / hg command line incomprehensible crap only added to my frustration. Friends said there were GUI clients, showed me Tower. Oh my god, so much stuff to look at, so many buttons to understand, so many rites to learn. For some reason, I can’t just commit stuff, I need to stage it first. No, I said, please, guys, let me just do my projects. And those “remote repositories”? Hate that. Everything is already here, on my machine. Why bother even thinking about putting it somewhere else? See, I didn’t like anything about source control.
Everyone was trying to convert me. They said hey, but how do you work in a team without source control? And I said, I either work alone, or I separate pieces of code into independent files. They said hey, but how do you revert changes if you’ve accidentally broken something, without source control? And I said, I use Time Machine. They said hey, how do you branch your code without source control? And I said, what the hell is that?
But there’s always been something I did want, and I knew source control could do it for me. First, I wanted to see what has changed in a project from a previous revision (to write a full changelog, primarily). Second, ability to comment the changes would be nice. Third, I wanted to be sure no code gets deleted just because Time Machine runs out of disk space. Finally, I wanted to seamlessly merge changes I’ve made on my notebook with the ones I’ve made on my main machine, if I’ve accidentally forgotten to sync them before doing something.
I was lucky enough to get the author of Gitbox, Oleg Andreev (who I happen to know personally), to spend some time on Skype with me and explain how to start using git with Gitbox. It turned out to be way easier than I had thought. You just drag a folder to Gitbox to put it under its control. Whenever something changes, it shows you the changed files (on the right):
To commit changes, you put checkboxes next to the files you want and write a comment in the field above the list. To see changes inside a file, you double-click its name. The project and its commit history looks like mail. Oleg explained to me how to “link” the project folders on the notebook and on the main machine: I had to set up the two copies as remote repositories for one another. This was the only non-obvious thing. Still, done in the UI with drag and drop.
So if you are like me and want to continue hating source control but still use some of its benefits, try Gitbox. Or if you are not like me and you’ve been a source control fan all your life, try Gitbox. You’ll love it.
