If you’ve worked at all with patching your own creations for music, visuals, and control, this has probably happened to you: you’ve made some change, and forgot what you did. You think of something you did some time ago – and forget what it was. Or you want to be able to easily collaborate with other people, and that means a lot of files flying around and no idea which file has which change. All of these problems are familiar to programmers. The solution: a technique called version control. Sounds fancy, but it’s really accessible to anyone, not just advanced programmers. And once you try it, you’ll never go back.
Git is a popular version control system that’s all the rage these days – aided by the star power of Linus Torvalds, its creator (who uses it for Linux kernels, not Max patches, sadly). Mormo aka Tomasz comes to the rescue of patchers with a complete guide to applying Git to patch management. Now, I’m a big fan of Subversion (“svn”) myself — but even then, you can follow the basic guidelines here and get something going.
Aside from the technical details of how this works, Tomasz gets into some of the deeper issues of what this is really about: sharing, collaboration, and openness.
Before you get scared away, just trust me on this: if you make patches, even simple ones, if you have zero programming experiment, you’re going to wind up loving version control. Naturally, this kind of version control could eventually be applied to musical materials and not just code and patches – and that’s when things get really interesting.
This works well for Max (and Pd) because it uses text-based patches. (Code will work nicely, too, lovers of Processing or Csound or SuperCollider or Chuck.) If you have binary files, it’s going to be tougher to do things like merges — sorry, Reaktor.
Hi, I posted the first two parts of a three part series on why and how a version control system (git) can be relevant to musicians creating software devices for their music. The monome application-creating community and its use of max/msp form the case in point.
SVN would work fine too. I chose git partly because i’ve started using git lately at my day job (web development) and i’m interested to get to know it better. Also i really like that its trivial to put an existing project under git control, just a couple of command line instructions and no need to explicitly configure a repository.
There have been complaints lately from certain bloggers that Git makes it harder to share a repository online. I asked about that specifically, and Tomasz responded:
From your git managed directory it can be as easy as running:
This will work if you’ve cloned a github repository as described here:
(though in the article i typed a more verbose version)