The best part of Git? More and more people are using version control and a lot of them aren't even developers. Just like Rails, the community and the social effect (aka GitHub) have made this possible.
At assorted Web design/development gatherings I've seen a big divide between coders types, almost all of whom use some form of version control, and designer type, whose idea of version control is the periodic use of winzip or stuffit.
Having more articles like this is Designer Land is fantastic.
I would urge developers who work with designers to consider arranging some sort of presentation, perhaps at lunch, about version control. Spread the love.
Git knows about three things; blobs, trees, and commits. A blob is a collection of bytes. It is stored on disk as a file containing the bytes named after the sha1 hash of the bytes. A tree is a set of mappings from name to a blob or a tree, allowing you to represent collections of blobs like they exist on disk. Finally, the commit object is some metadata (author, committer, date, message, etc.) and a tree object. Add some shell or Perl scripts on top of this, and you have Git.
So if you can write a simple shell script, you can make git do whatever you want it to do.
(That's why git seems so "messy" from an implementation standpoint, it's a bunch of shell and perl scripts that do random things. Darcs and Mercurial have a slightly more complicated model, and hence everything has to happen "inside". This results in a cleaner looking interface, but a lot less hackability.)
The downside is that the repo grows by that much every time I update the file. The upside is that I get a version history if I need to back out to an older version!
The problem is that web design inevitably ends up in pixels, and I will always have to move to that level to tweak, anathema to version control.
> Because Subversion doesn't store revision history on the client, it is well suited to managing projects that deal with lots of large, opaque binary files. If you check in fifty revisions to an incompressible 10MB file, Subversion's client-side space usage stays constant The space used by any distributed SCM will grow rapidly in proportion to the number of revisions, because the differences between each revision are large.
> In addition, it's often difficult or, more usually, impossible to merge different versions of a binary file. Subversion's ability to let a user lock a file, so that they temporarily have the exclusive right to commit changes to it, can be a significant advantage to a project where binary files are widely used.
[1]: http://hgbook.red-bean.com/read/how-did-we-get-here.html
And I just googled before posting, but it looks like it's been ported to git: http://code.google.com/p/tortoisegit
The article at least implies that you'd be better off on the command line and it's not that bad. But my experience is that to others it can be a turn off.
http://github.com/brotherbard/gitx/downloads
I don't actually use it to commit because I have a screwy commit flow, but I'd expect it to work for a basic commit cycle.