found drama

get oblique

Git with it!

by Rob Friesel

git logoPartly for my own enjoyment and partly to respond to Tweets from two friends of mine, I’d like to write a little bit about my experience with the Git source control manager.

Before we get too far in this process though, let’s get one thing out in the open.  I’m probably the least technical developer out there.  I’ve used Subversion “lightly” for a simple development project for about two years and CVS at the office for only about the past six months or so.  So keep that in mind as we move forward here:  my frame of reference is not a terribly technical one and is likely not to answer any burning questions that you may have about branching or anything else that moves into terribly complex terrain.

That said, my thoughts re Git versus Subversion and/or CVS?


From a strictly user-experience perspective, Git is a simpler, friendlier source control system.  It seems to be a little more forgiving of your blunders and makes it easy to back yourself out of a corner if needs be.  It’s less worried about your conflicts because those are your conflicts until you try to push those commits up to the origin (the central, master repository).

Git has its own Domo Kun?“What?” (you ask) “Central, master repository?”

Yes, that’s right.  By all accounts, Git is a distributed versioning system.  From the Git website:

Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do.

The way I like to think of this:  every time you check out the project from the origin, you are creating a branch.  And all the development that you do on the project, every commit that you make, is committed only to that branch.  And when you’re satisfied with your changes, you push those commits to the origin.  Coming from Subversion and CVS, it feels like making a whole bunch of low-risk “micro” commits and then one great big giant commit to push all those changes back up to the central repository.

So what about branching then?  Well, I haven’t really done that yet.  Part of the reason for trying Git in the first place was because I was having a bear of a time getting branching and tagging to work properly1 under Subversion.  If I was wrestling that much with Subversion’s branching anyway, why not just Git a whirl?  Which is approximately where I’m at right now.  Again, each checkout feels like its very own branch.  Now, I’m at least smart enough to know that these are not true branches.  I’ll get there at some point.  But for now I’m just glad to be using a version control system that doesn’t bitch me out every time I try to commit a file.

While we’re on the subject…  Publishing/deploying projects has also proven to be much easier compared to the strategy I had going for Ortho under Subversion.  Under Subversion, I did my work, updated to resolve conflicts2, made my commits, then SSH’d into my web host to re-checkout the project into its correct directory — and then hope that that did not introduce conflicts into the published version3.  With Git, it seems like all of those conflicts are resolved cleanly and stay resolved once your changes pushed into the origin.  It seems to me that this because you resolve your conflicts in your distribution of the repository before Git will even let you push those changes into the origin.  At least, in my limited experience thus far, Git seems to politely decline when you try to do something unwise.  Anyway, my points is that you can feel about what is in the origin — that is nice and stable — so when you want to deploy, just go to the location for your deployment (e.g., in my example case $WORDPRESS/themes/ortho) and type: git pull git://

Bam.  A cleaner deployment there never was.

An exhaustive review?  Hardly.  Detailed and technical?  Not a chance.  Nevertheless, those are my (amazingly, uniformly) positive impressions of Git after spending about a week with it.

For other impressions on Git, try this write-up on Webdesinger Depot. And if you’ve decided to try out Git, do yourself a favor and download Zack Rusin’s Git cheat sheet post-haste.

  1. Read as: “at all”. []
  2. Which always seemed stupid for a project that had only one developer…  But Svn got mad at me if I didn’t.  So I did. []
  3. Which managed to happen on a number of occasions. []

About Rob Friesel

Software engineer by day, science fiction writer by night. Author of The PhantomJS Cookbook and a short story in Please Do Not Remove. View all posts by Rob Friesel →

2 Responses to Git with it!

Scott McCracken says:

Nice breakdown, it was quite helpful to hear these experiences because we share a similar perspective: we understand the importance of versioning systems, but might be a bit more interested in the usability of each system over the technical side. Thanks for the write-up.

Leave a Reply

Your email address will not be published. Required fields are marked *