Git (or my take thereof)

(Image used under Creative Commons License.  Artwork by Azizash http://azizash.deviantart.com/art/GIT-Logo-95183398)

Flame Wars and Religion

My Usage of Git

Some of the things I love about Git are:

Some of the things I dislike:

My perceived problem of Git

The real issue I take with Git is simple, it's too complex to serve as a good fast, flexible, and usable tool for most people and companies. Most people, using SVN, are content with updating a branch and committing their changes, this is usually done by:

svn up
svn ci -m "Message"

The equivalent in Git is:

git fetch | git pull
git add [File Handles] 
git commit -m "Message"
git push (If using a central repo)

The problem here is complexity and choice, now not only do you pull (fetch & merge)  but you can also fetch & rebase which takes your branch back to what it was originally, adds the new, and then reapplies your changes, and this doesn't even cover what happens if your branch isn't setup to track where you want to pull from or cherry picking.  Nearly every example using git vs. svn is the same, there are a bunch of choice, new commands to add, and ways to deal with the problems your own choices create, plus now you have to keep track of multiple sources, that may or may not be up to date.  If you really want to complicate matters, start adding multiple branch merging, pull requests, order of merges,  bisecting branches, and the issues interactive merges can create.

The benefits of Git

I wrote earlier that Git gives me a million and one ways and I showed how that complexity really can screw you up if you're not aware of it or capable of handling it.  The reality is though, SVN (and CVS by extension) is completely inflexible, slow, and basically not powerful to handle most large projects with multiple developers and versions/features.  I've personally found great use with Git as a personal repository pushing to SVN (using Git as a client) because I prefer to branch off a stable branch when developing new features (rather than polluting a stable branch) and committing at any minor milestone.  Further some of the tools out there for Git (Github) are completely awesome for social development. If you have the time and capability of learning Git completely, it's a very powerful tool to wield, perhaps with a dual edge since it seems rather easy to slice yourself if you just foul up a little.

A pragmatic approach

My proposed solution is a simple one, merge some of the functionality from Git with some of the philosophies of SVN.  What do I mean by that?  Well, Git is a very powerful tool written for Kernel development (that should say everything about why it's as complex as it is) I would suggest merging a good chunk of it's functionality with the existing (and proven) philosophy of SVN, this includes simple commands without difficult to understand required switches or varying functionality defined by switches, then take the distributed system and apply on top of the existing model of a centralized server.  To further dig in, I think distributed nodes with a centralized main repo (that's enforced) where the main repos consistency is enforced to the nodes.  Maybe this would be better, maybe it wouldn't be, but from my perspective it makes a lot more sense.

A solution for now

Currently you can use Git as a SVN client, maintaining a local repository of the remote SVN repository using git-svn.  By using the tools this way, you still get the best of both worlds, only major issue left is that there isn't full compatibility with Git and SVN and it takes forever to update a SVN repository especially when branching/tagging is involved.  If, however, you are comfortable with using Git as a central repo (detached head for example) then I strongly recommend using Git-Flow (Awesome Blog entry about Git-Flow) it'll ensure your branches have some sort of sanity.

Conclusion

While Git is an awesome powerful tool, it can be overwhelming for someone who doesn't appreciate all of the functionality or the time spent learning the functionality and the underlying philosophies.  If you are mulling over using Git and are uncertain, please don't do it just for the sake of saying we/I use Git.  If you have a real need, and don't mind the additional complexity, you'll wonder where this tool has been all your life, otherwise you'll just be pulling your hair out and considering what you were thinking.