"The best part of Git? More and more people are using version control and a lot of them aren't even developers"

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.

I think the analogy with Wikipedia is a pretty good one for explaining version control to people who have no idea what it is. Often web savvy types have at least seen the history of a Wikipedia article before and can use that as a reference.

How well does git handle non-text files like .psd and .ai files?

According to "Mercurial: The Definitive Guide" by Bryan O'Sullivan [1], it might make sense to use Subversion if you are collaborating with others on said binary files:

> 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

I have a git repo that seems to do fine handling binary files of 1-200 megabytes that regularly update.

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!

Also, you can't diff or merge them.

Thats not gits fault. It would need to know how the programm that preduced the file does updates or some professor somewere has to figure it out on bitlevel.

With the push in the design community to create some sort of replacement for psd comps, I could see a new file type becoming accepted.

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.

It can handle whatever you put into it, but obviously won't be able to diff them.

Can you provide your own diff-programs for different binary formats?

Of course.

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.)

I've suggested people use it for their office documents.

Although I like the CLI interface to some of these tools, I think to get people using them you need nice GUI tools and sadly these are lacking - or rather they were when I last looked.

For git, perhaps, but subversion has Tortoise SVN which integrates nicely with windows explorer.

And I just googled before posting, but it looks like it's been ported to git: http://code.google.com/p/tortoisegit

I was trying to turn on some applers to the joy of svn, and the tools at the time were immature, though that was two years back. Tortoise was great on windows though. I thought GIT didn't play well with windows - so a git-tortoise would be welcome.

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.

TortoiseGit is pretty usable on windows. You should try it.

http://code.google.com/p/tortoisegit/

My only gripe are the icon overlays. I still get randomly missing overlays.

Git used to play badly with Windows. It does fine now.

If you're on OS X, bortherbard's fork of gitx might work if you're looking for a graphical option:

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.