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:
svn statuswill yield this:
? lame/cssIndicating 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 controlThis 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 DamageMaybe 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 RescueGit 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 DetailsWe 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.
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 MoveIf 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.