Here are the top reasons I am a git fan:
- price. Depending in the implementation choice, it can be free (as in free beer!). Using a service like github.com to facilitate in a centralized workflow is super cheep. Currently for a year’s service for 10 developers we are paying about $25 a year per developer for the github service (and 20 “private” repositories). Scaled up a bit it’s relatively the same cost at $24 a month per developer for 1 year (100 developers, 300 private repositories).
- cheap local branching, merging & tagging. It’s sinfully easy to do. As fast as you can 10 characters and a branch name, it is done. It’s all local, so it’s virtually instant. Easy branching means you are more likely to do it & that can lead to better development as a whole. Isolating a feature, bug fix or re-factoring into a branch as a standard can be very rewarding. Merging is relatively straight forward, fast & in some cases completely automatic. Tagging allows for you to give the code a name at any point in time — like “release 1.2″, or “hotfix”. You can very easily switch to a given tag (or any commit) and work on it via a new local branch.
- Fast. everything is local. Besides syncing up with other people, pretty much every interaction with the source control is local. This becomes a huge time saver — and again, when it’s quick you are more inclined to use it. Branching, merging, looking at code history and committing are all practically instant tasks. Yes, git is faster than most source control systems out there. Oh yeah, and all revisions of every file are always locally available for you to inspect. Again, this can be a big performance booster of you are comfortable with the command prompt. When you do need to do network opperations like pulls & pushes, it is also very fast. Git uses diffs and compression to make these also very fast. “raw, blistering speed.” Does that make you think of other source control systems?? no? didn’t think so…. 
- several workflows. You can follow the traditional centralized repository approach as we currently do with github. A master repository is designated, and people pull/push to that repository using it as a centralized sync area. This is very similar to the perforce workflow. Alternatively though, there is a “Dictator and Lieutenants” workflow that basically allows for anyone to sync up with anyone else’s repository. A “circle of trust” is applied here each developer trusts other developers in their commits — and each developer trusts certain people with that they have contributed. This works well for larger groups. Think of a triangle scheme, with the sr. developer (the dictator) trusts a few others (lieutenants), and those lieutenants each trust a few others, etc.
- easy to learn. You basically learn what you need to do your tasks. You may only need to do a few things with the files you are putting under source control. Maybe you only need to know “git pull”. If you only need to make sure you have backups of a file locally then you only need to know 1 or 2 commands. Done. If you are a source control master, there’s more git functionality than I can shake a stick at…. I get by using probably 2% of git’s core functionality. And when I need more, I do a google search & there’s a ton of user contributed info on how to accomplish a given task at hand.
The important thing to note here is that git has some major benefits in certain cases & although it is not for everyone, I think it has some major wins in certain situations.
As Mr. Natural said “Get the right tool for the right job”. In other words, one tool may not be a good fit for any job at hand.
Oh yeah, github.com is the bomb. Look out for http://fi.github.com. It look killer if you need a github UI but internally (possibly due to corporate policies / restrictions)
slopsbox is discussing. 
, and 
Jim Schimpf are discussing. 
Shannon McPherson, 
slopsbox 12:58 pm on November 2, 2009 Permalink |
Better be careful with that. I once negleted my 3 hamsters for a few days. Came back to only find 1 and a shitload of tiny bones.