Git for Making Music

I have a powerful new tool for making music: git.

Programmers are to source code as studio musicians are to project files:

  1. We make changes that we later decide we don’t like. Git makes it painless to manage huge numbers of files, to clean up cruft without fear of losing it forever, and to revert back to earlier versions and begin anew.

  2. We copy (“branch”) our files to speculate on larger changes. Git’s branching features are a main attraction for programmers; I’ve found them equally indispensable for my 52.WKS project.

  3. We try to understand what’s changed over time. Here, unfortunately, tools are lacking for musicians. Most of the files we maintain are binary. Many, such as project files, are likely to be proprietary. I can only hope for a future where I can visualize changes to projects and waveforms just as easily as I do today with source code.

The system isn’t perfect, however. We’re one-quarter through the 52.WKS project and already git is struggling a bit. My 52.WKS repository weighs in at just over 1GB — a completely manageable size, though large if you consider I only have thirteen effective minutes of audio to show for it. Git repos are content-addressable, so git is going to be slower at managing large binaries. For example, there’s noticeable lag when I run git status.

Whatever the case, it seems that git will scale well enough to allow me to keep the full 52.WKS project in one repository. As a result, I suspect git scales well enough to manage the lifetime of an entire album — something all serious musicians should consider!