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.
