Using Git when you're making music
Wed 25 Jun 2008
I'm a programmer. This means that when I see music files named things like "Bumpy Bosbo Version 2 (longer).als" I feel a tangible pang of physical pain. When you're programming you keep the file names the same and use source control to track different versions of files.
Music software tends to produce folders with a few large audio files (tens of megabytes, not video large) and a small project data file (.als, .rns, .logic) that contains the arrangement and all the other stuff that you've done to your audio files.
Your audio files are unlikely to change once you've recorded them (unless you've a penchant for destructive editing - something I personally don't bother with any more since all the real-time non-destructive dsp effects are so fast these days).
Now - with Subversion it was always too much of a pain to mess about committing files to a repository - the only working ones I had were remote and I didn't want to be sending my audio files over the internet -- way too slow -- and I couldn't get a local svn repository working (I might've managed it if I'd spent a bit longer but I was on Windows back then and it was just too much bother).
The beauty of Git is that you don't need a remote repository. You can initialise any folder on your hard drive and mess with versions quickly and locally, without having to set up a structure in a central repository.
I'm going to run through how I do this on a Mac. If you're running Windows, I would suggest getting Cygwin so you have a proper Unix prompt and install Git through that.
You can find instructions for installing Git on Google. Search for "installing git".
Then, it really is as simple as this:
Now, say you want to try a different version of a track, you make a new branch.
Now any changes you made will be on this branch instead of the original. Commit changes as you go with
If it all goes wrong, you can switch back by typing
Reload your project and you'll be back to the old version. If you want to be able to get back to your experimental branch, make sure you commit those changes before going back to the master branch.
It's fast, and you can now experiment with impunity, safe in the knowledge that you can get back to any older versions of songs at any time without having to manage a load of sleepily named files.
Let me just recap in a sort of reference-card form:
Music software tends to produce folders with a few large audio files (tens of megabytes, not video large) and a small project data file (.als, .rns, .logic) that contains the arrangement and all the other stuff that you've done to your audio files.
Your audio files are unlikely to change once you've recorded them (unless you've a penchant for destructive editing - something I personally don't bother with any more since all the real-time non-destructive dsp effects are so fast these days).
Now - with Subversion it was always too much of a pain to mess about committing files to a repository - the only working ones I had were remote and I didn't want to be sending my audio files over the internet -- way too slow -- and I couldn't get a local svn repository working (I might've managed it if I'd spent a bit longer but I was on Windows back then and it was just too much bother).
The beauty of Git is that you don't need a remote repository. You can initialise any folder on your hard drive and mess with versions quickly and locally, without having to set up a structure in a central repository.
I'm going to run through how I do this on a Mac. If you're running Windows, I would suggest getting Cygwin so you have a proper Unix prompt and install Git through that.
You can find instructions for installing Git on Google. Search for "installing git".
Then, it really is as simple as this:
- open up a terminal window
- cd to the folder with your track in it (I tend to type cd and then drag the folder from Finder into the terminal. It's worth paying attention to the little icons you get at the top of document windows - you can hold down and drag to get a handle on the file, or you can right click to get the folder hierarchy and then go from there. Doesn't work in Ableton Live though :-/ )
- Type
git init. You now have a repository. - Type
git add "My Song.als"where "My Song.als" is the name of the track you're working on. It might be .logic or something else. The important thing is that if it's likely to change then you need to add it to your repository. That goes for audio files too. If you don't have that much audio then it's quicker just to saygit add .to add everything. - Type
git commit -m "a description of what you changed". You're now ready to start messing with stuff.
Now, say you want to try a different version of a track, you make a new branch.
git checkout -b experimental-branch (where 'experimental-branch' is the name of your new version)Now any changes you made will be on this branch instead of the original. Commit changes as you go with
git commit -m "what you changed". If it all goes wrong, you can switch back by typing
git checkout masterReload your project and you'll be back to the old version. If you want to be able to get back to your experimental branch, make sure you commit those changes before going back to the master branch.
It's fast, and you can now experiment with impunity, safe in the knowledge that you can get back to any older versions of songs at any time without having to manage a load of sleepily named files.
Let me just recap in a sort of reference-card form:
cd /Your/Project/Folder | Go to your track's project folder |
git init | Initialise the version control (you only need to do this once for each track) |
git add . | Add all the files in your project folder |
git add "Individual Files.file" | Add files individually if you don't want to double the size of your project folder (not a problem unless you have LOADS of audio takes in there, and even then it'll only be a bit slow on the first commit and fine after that) |
git commit -m "Commit message" | Do this as frequently as you can, especially before branching |
git checkout -b new-branch | Create and switch to a new version of your track |
git checkout master | Return to the original version of your track |

0 comments on "Using Git when you're making music"