The One Critical Reason We Switched from Subversion to Git

wrote this on in , . 13 reactions

Git is not just for open source and uber geeks; we have been using it here at ZURB for over a year, with much improved efficiency over our previous workflow with Subversion.

I could explain all the amazing things that Git does in regards to branching, merging and distributed workflows, but I can already see your eyes glossing over, so I'm going to boil it down to the single feature that benefits all people, not just the ones managing branches of branches of branches (that was three levels deep, are we in limbo yet?).

Tracking Every Folder with a .svn Folder

You want some folders with your folders right? For each project in Git, you just have one .git folder that tracks all the changes in the project, as opposed to Subversion that has a .svn folder in every one of your project folders, which looks something like this:

Every folder has a .svn folder used to track the files within, which is not really a problem until we try to copy the css folder from awesome to lame. An svn status will yield this:
?       lame/css
Indicating that the folder is new and currently not tracked by Subversion.

Great, let's add it with svn add lame/css and get this misleading warning:

svn: warning: 'lame/css' is already under version control
This sucks for two reasons, first it's not really a warning since the file was not added, second you don't get any indication of what you should do next.

Repairing the Damage

Maybe you know that you need to delete the hidden .svn folder from the folder you just copied, requiring that you know how to reveal hidden folders, or do this from the command line. Or maybe you just start copying other files, deleting things, adding more files, copying, pasting, and then coping again, at least crying out to the nearest engineer to help you untangle the knot of code you have tied around your neck.

The example above is fairly simple to correct; when we were using Subversion here at ZURB, we encountered similar but more complex situations at least once a week. We have a high volume of code flowing through our lives, from products, to client code, to playground pieces, so folders (often with many subfolders) get copied or moved constantly, and the constant repair of .svn folders was just unacceptable.

Git to the Rescue

Git tracks all files in the project with a single .git folder at the root of the project. You can move folders freely without ever getting yourself into trouble. While Git has some of its own quirkiness around remembering to push and pull (syncing your local work with the remote code repository) after committing your work, the amount of time spent untangling code knots has dropped to almost nothing. And we've never encountered a problem that resulted in the loss of work.

Workflow Details

We use GitHub to host our code. It provided a nice interface for browsing code history and managing permissions. It's also a nice place for distributing our plugins and playground code.

Most of us work from the command line interface, but a few like GitBox, an OS X app similar to Versions but for Git.

We use branches, and keep the master branch deployable 24/7. That means if you commit something to master that does not work, you are a code fister. If someone needs to work on something experimental, or incomplete, they do it in a branch.

Making the Move

If you are ready to make the move, make sure you have someone on your team who is familiar with Git, or committed to learning and owning the transition. You also don't need to do it all at once. We started by moving one project over and getting everyone on the team comfortable with committing changes before forcing them to do everything through Git.

If you still have questions or concerns about making the move, feel free to share them in the comments. We would be happy to discuss, or hear your own version control (Subversion or Git) horror stories.

Swing and a Miss
You're Design Thinking Too Much
Design pot
Design or Get Off the Pot

It has 9 comments.

Dave (ZURB) says

I think everyone should git with it these days - Git has made working collaboratively so much easier. Both require some command line mastery, but Git errors are much easier to parse and fix.

Git also has the awesome advantage of a community and a web-client which makes public, open-source pieces (like our very own Orbit and Reveal) much easier to work with.

Duncan Heal (ZURB) says

Tower is a very worthy Git app, just recently out of beta. (I have no connection with the company)

Matt (ZURB) says

Duncan: Tower looks nice, we'll take a look.

Chris (ZURB) says

I used Tower beta and I liked it. Haven't checked it out since then though, I tend to stick to the command line.

David Keegan (ZURB) says

If you guys haven't checked out Tower yet I'd definitely recommend it for working with git.

Daniel (ZURB) says

GIT is a lifesaver. Makes deployment super easy too! <3

Kevin Pearcey (ZURB) says

While git is great (and I'm currently converting many projects to it - via svn2git), if you truly want to know the history of the files you are using then you should use the scms commands to help you: svn cp

There, you've copied the files and added them to source control in one command.

Christofr (ZURB) says

Having .svn's in each of your subfolders does allow you to decouple a folder from its location within a tree.

For instance, if (for whatever reason) the location of a subfolder in a repository doesnt suit me, I can move the subfolder locally on my disk, and continue to update and commit to that subfolder as if nothing had changed.

Matt (ZURB) says

Christofr: That's true, and I assume the requirement that led Subversion to being designed that way. We used to store many projects in a single svn repo using this feature, but it led to the following problem:

Subversion savvy people just checked out the projects (subfolders) they needed and it worked great. Less savvy people just pulled the entire repository and did a svn up on the entire thing.

Depending on their last svn up, and changes to other projects, this command could take minutes, and the issue of copying or moving files, without using the correct Subversion command, was compounded by the slowness of having to work with a monolithic repository.

It's been much simpler for us to just have projects that you clone, and remove the temptation of getting everything.