So, I’ve Tried Git. And it’s… « planetOzh

I'm a SVN user.

Nowadays, all the cool kids have a Github account where they host stuff and use Git as their primary Source Control tool, and prefer it over the usual SVN you've probably got to use.

I'm not a cool kid and for the last few years (since WordPress started the plugin repository using SVN I think — more or less 8 years ago), I've been happily using SVN. You know SVN, right? Easy to use and to understand, right? Does the job simply, right? So, why switch, right?

I'm regularly pestered to move YOURLS from Google Code to Github, to which I responded more or less that I was happy with SVN and I didn't want to spend time learning a new complicated tool. Because, Git is complicated, right?

But I wanted to be a cool kid anyway, so I gave Git a few looks and tries.

First pass: what others say

A couple months ago, I decided to investigate that Git stuff. From a few blog posts I skimmed through here and there, I knew that Git was supposed to have a few advantages over SVN. Any "Git vs SVN" article will list a few amaaaazing advantages, which are always:

Git is distributed. I'll be damn if that made sense to me: what I need is a computer where I code and a repo where I commit, right?

Git is fast. Wow. Maybe, but, errr… it's not like I really need to shave 5 seconds off the 15 seconds that my commits take, right?

Git is more efficient, disk wise. I knew that, for instance, Git tags are just pointer to a particular commit, while SVN tags are a joke because it's a whole folder where code is duplicated. And yes, that made sense to me, but I still didn't care because, honestly, who needs tags? I don't. Plus, I can haz gigabytes of empty disk space, so a source control tool that'll save me a few megs isn't really a life saver, right?

These were the pro-Git arguments I've seen everywhere, and I wasn't excited. Sure, seems cool, but definitely not something cool enough to be worth the hassle for me.

Second pass: theory

I searched the web for all the Git manuals, starters, tutorials and handbooks I could find and ended up with reading the Official Git Documentation which is, I must admit, pretty well done.

In every tutorials and guides, the first basic steps are easy and won't get a newbie SVN user lost: you edit a file, you commit it. Wait, then, you push it. Soo… in SVN I edit and commit, but in Git I have to edit, commit then push? Okaaaay…

Then, in every tutorials and guides, my interest went decreasing as I was reading more and more about complicated concepts and features light-years from my actual needs, such as "branching" or incredible log viewing abilities or god knows what.

Seriously, I thought, why on Earth is every cool kid using that tool and advocating it like it's what Jesus and Chuck Norris would use?

Third pass: practicing a bit

One day, I was playing Alchemy on my phone: it's a fun little game where you combine elements by dragging one on top of another, and sometimes it creates a new one (like, drag the Earth icon over the Fire icon and boom, it creates Lava, something like this). I thought: "heh, this is fun, I'm sure I could do this in Javascript, it's all about jQuery draggables".

One other day, I came across an article on Github's blog about a Game competition: create a web based game loosely related to cloning, merging, forking, or anything Git-esque. Nice initiative from them, the world always needs more web based games :)

And finally, one other day, I realized that Alchemy was loosely related to these Git concepts: you clone Earth and you merge it with Fire to create something. Heh, I thought. Why not. Let's participate.

So I created my first repo in my empty Github account, and I started something different: not trying to learn Git from theory and books, but from real practice, just step by step, humble newbie step by cautious newbie step.

Rapidly, three things happened : a "hey cool!", a little relief, and a fucking ZOMYGOD.

The "Hey cool!": where complicated makes sense.

You've already created a SVN repository and found it easy, right? Just set up an online repo, checkout its content to your disk. Can't be easier, right?

Well, yes, it can: inside any directory, click "Create Git Repository here" in TortoiseGit, or "git init" if you're the 2D console type of coder, and that's it, you already have a full-fledged repository where you can commit, revert and track changes.

Suddenly, the three-steps workflow (remember? edit, commit, push) made sense: everything is local! you don't even need an internet connection to work with your repo! No wonder they say it's faster. You can commit and revert locally, then eventually push on the remote repository and share with the world when it's cool enough. Or you can even create a quick repository for a quick local project without even needing an internet repo.

And that, I thought, can be an interesting development pattern.

The Relief: OK, it's actually easy.

Once I understood that 3 step workflow, I didn't find Git any harder to use than SVN for my very basic needs: code, try, edit, change, revert, edit, fix, save. Sure, it can be a frustrating feeling to use 3 simple commands where there seems to be like 300 complicated ones, but when you just need a hammer and are given a complete hardware store, well, just use the hammer.

The Fucking ZOMG: Git's killer ninja nuclear godzillesque feature: Branching.

OK, onto finally the real reason I'm writing this whole post :)

On Github, once you have a repository (http://github.com/joe), you can also easily publish to a live website (http://joe.github.com), and, for this, you have to create a new branch named 'gh-pages'. Since I wanted my web based game to be, well, playable on the web, I thought it might be a nice occasion to play with Git branches.

I knew branches from SVN: they are folders where a particular branch of your code lives, and you can modify it without modifying the "master" branch (aka trunk in SVN), to eventually merge branches later. This is probably cool and everything, but it implies juggling with directories and that's cumbersome. I for one is annoyed by the trunk/branch/tag directory structure enforced by SVN. I want to code in a live directory on my web server, and SVN insists that I copy that into a lame trunk/branch/tag folder.

So, branches with Git. And now, my fellow SVN-accustomed Git-ignorant coder friend, open your eyes and read carefully what happened.

First, I created the branch 'gh-pages'. "Hmm, I must have done something wrong", I thought, I was expecting something like a new folder named 'gh-pages' where to put new stuff.

Oh, OK, I have to "checkout gh-pages", ie switch to that branch. God knows where that'll take us, but let's do it. I did, and, again, saw nothing particular happen. "Well, I thought, I'm following the step by step tutorial, so let's just pretend this is normal". I added a few stuff in my working directory, and committed.

So far, so good, except I still didn't understand where I was exactly, since I was still working in the same directory. Where's main branch? and the new gh-branch? I was slowly getting lost, so I decided to start all over again, and switched back to the "master" branch. And what happened? My newly committed files disappeared.

Since I was sober at that time and pretty sure I had created and committed files, I boldly didn't panick, didn't move for a few second, hands hovering over the keyboard, and slowly started to realize and understand. Oh. My. Gawd. You can work on multiple branches, it just happens in the same directory. Git just make files appear and disappear as they belong to the current branch or not. Oh. My. FUCKINGGODTHISISAWESOME!!!1!!

Today I began playing with Git branches, and, dude… http://t.co/gHhey1IX

— Ozh Richard (@ozh) November 6, 2012

Look at the following two images — for the sake of screenshotting I use the command line client, but TortoiseGit has the same ability — you can switch between branches without having to work in different directories.

That. That is pure awesomeness. Why on Earth isn't this mentionned in bold typeface on every Git vs SVN article? "Git is magic and changes branches without bothering you with different folders". Forget about all the distributed shit and other history logging stuff, THIS is the crack.

"And why is that so cool", may ask the one or two readers still with us at that point?

Imagine working on your regular project, WordPress plugin, whatever. You're coding and seeing live results in http://127.0.0.1/myproject and suddenly you want to test something crazy in uncharted territories. Chances are, you make a copy of plugin.php and library.js, and begin modifying them. So, basically, you're working with duplicate files. Meh. In Git, simply create a new branch off your current work (one click or a console one-liner), edit, revert, and if you're happy with the result, merge back (another click). No need to have multiple directories to keep duplicate files.

That is fucking awesome. Seriously, people writing guides about how cool and practical Git is, make this big and bold and clear and unmissable from the start. Forget about the rest, emphasize THIS.

So, whatcha think, Ozh?

Man, I'm sold. Did I say this is awesome already? I've only seen and understood the tip of the iceberg, I may even never need more, but initializing a repo in a blink and instantly switching between branches is, dare I say it, life changing. I even tried to explain how cool that is to my wife, but that battle remains yet to be won ;)

There are a lot of complicated things in Git because, again, it's a complete hardware store and most of the time, you'll need a simple hammer to do a simple job. And that's fine: just use the hammer, and the one day you need complicated tools to perform a complicated task, you know you'll have something in store and someone or a tutorial to explain how it works.

Retrospectively, I see why I have been a bit hard to convince.

Github is sexy and powerfull, but it's not a Git client

Github is definitely one of the reasons why Git is so succesfull: the interface is sexy and very elegantly functional. It's so beautiful you just have to be a part of that.

Its paradoxical limitation is that it can give newcomers the false impression everything can be done from within the web interface: share with the world, receive and review patches aka "pull requests", patch your code. So, when the said newcomer wants to perform something a little more complicated, newcomer gets lost because newcomer cannot find the appropriate menu for the desired action. I was that newcomer.

Same comments go to their desktop client: sexy apps for sure, but I'd recommend skipping them. I started Git with the Github client because I thought it would be easier, but everything got much more intuitive when I installed TortoiseGit which combines simple and powerful. Github's Git client is appealing, but is half baked. No offense, Github.

Practice first, read later

Sure, that sounds like the dumbest advice ever: everybody knows it's easier to learn something while practicing. But it requires something you may not have at hand by the time you'll want to investigate Git a little: a real life project, no matter how modest, to test drive things. I didn't have a new project to play with when I first tried Git, and following step by step tutorials in a meaningless directory over random files just doesn't work. Or at least my brain isn't wired that way.

Find the right teacher

As I've said, the official Git documentation is really neat. But it's not a tutorial, it's a reference: it explains it all, including the hardcore complicated stuff, and will quickly get you lost if you're not in desperate need of something hardcore.

The best guide I've found to suit my needs was Git Magic. Pleasantly written, funny even, and advocates just what I wrote above: start little, and if you don't need more than the very basic commands, that's very fine.

I'm not very found of cheat sheets, which I often find pretty and unusable, but I've appreciated that one. It covers a few key concepts and doesn't try to be an all-in-one A4 sheet.

So, I've tried Git, and it's…

(admit it, you've scrolled all the way down to here without reading the article, haven't you? Naughty!)

It's by far one of the most amazing tools I've ever put my hands on. I was happy when I discovered SVN because it was handy, but I'm all wet for having discovered Git because it's magic. I just don't get why heavily collaborative projects such as WordPress don't gitify their platform.

If you're nice to your sister, a next post will briefly (briefly that time, I promise:) cover a few environment tricks on Windows to make you comfortable with Git. Nothing rocket science, just a few tips.

Excuse me, now I need to find myself a Git tshirt, because when I like something, I want a tshirt of it :)