There are obviously many reasons why Git is awesome (and why it sucks too), and there comes a point where it helps to dispel some of the rumors and issues surrounding Git. The following list attempts to show what Git is not. If you have your own reasons, feel free to contribute them to the comments and they may be added in.
Git works a lot differently than SVN and CVS. Probably the biggest difference is that Git stores content primarily, and it works mostly by taking snapshots of the information available. (This is why Git is commonly referred to as a ‘dumb information tracker’). Its algorithm for storing changes is fundamentally different from Subversion, and it much more efficient at doing so.
Also, if you’re used to having all of your projects in one huge repository, Git doesn’t really work like that either. Repositories are meant mostly for single projects, and then you could use submodules that link to other repos if needed. A tip covering how to deal with this situation will definitely be coming in the future.
The differences between Git and SVN could be in their own series of tips, but the Git-SVN Crash Course does a great job for those considering making the switch with drawing parallels.
Local commits are a huge advantage to using Git, and it means that your workflow can be made a lot smoother since it’s not talking over the network to a central server for most actions. If you want to know more about how this works, check out this post on the staging area or this one on pushing and pulling.
Another awesome advantage is that there’s one place where git stores its files for your repository (usually the
.git directory) and it doesn’t litter your working copy with thousands of hidden directories and files like SVN does.
Git can be installed on virtually every modern operating system, and it definitely works on Windows. GUI support isn’t there 100% on Windows, but plenty of work is being done on integrating into Explorer and to the various IDEs available. There’s plenty of slick tools available on other operating systems such as GitX on OSX.
Setting up a Git repository is as simple as doing
git init in any directory. It can’t get much simpler for that. Sharing your changes with others is when things get a bit more interesting. Usually sharing your changes is one or two commands away. Hosting your changes somewhere the right way can be a little tricky though: usually for self setup the best way to go is using gitosis, which is an tool that helps with getting SSH keys for users set up for commit access.
Git’s manpages are quite extensive (and verbose), but there are plenty of other guides available for learning online. Some of the best are listed in the resources section in this site’s footer! For those new to Git, I usually recommend the Git Community Book and running through some of the GitCasts videos. (Reading this site counts too!)
Yes, there’s a lot of alien terminology and some concepts that aren’t instantly familiar to every newcomer, but the underlying concepts that the system is based on are fundamentally and purposefully simple. One great example is the blob-tree-commit structure. Once the basic concepts behind Git are grasped, it’s really easy to make the tool work the way you want it instead of letting it force you into a specific workflow. Sure, too much flexibility could be a bad thing, but when it offers so much power and ease of use, why not?