This is a follow-up of one of the first posts here keep-track-of-versions-of-your-song-with-Ableton. At first this was a bit tricky, because you could choose leave out large files, like .wav recordings and samples and even the .als project files. Or you could defy a warning from Git stating that it doesn’t handle large files well, performance-wise. This will hit you when you push and checkout your repository remotely. Now you can start using the new Large File Storage (LFS) feature, that handles versions of the large files as markers in the Git repository, improving the speed at which Git can handle these large files when getting the latest version remotely. Please note that these versioning tools might work for your DAW too.
But why Git versioning?
Lets go back to the beginning. Why should you consider using Git for versioning of your Ableton Live projects? Version 10 of Ableton Live keeps backups of your project files. If something goes wrong, you can go back 20 or more versions. The problem is, what version on which time and date contains which changes? There is no way to tell. With Git versioning you can attach a message to each set of changes (commit) and you can decide which part of which commit you want to keep. The thing that holds most people back from using Git is its complexity.
Git is even more powerful in combination with a shared remote repository like GitHub or Bitbucket. This will allow you to work together remotely on a shared project with more musicians, while at the same time giving you the liberty to work stand alone. Contact me if you want to hear more about this. Please note that some remote repositories are not free if you want to store private content and collaborate. Otherwise everything you put on it is public. GitHub now allows free private repositories.
With its power comes a set of command line instructions that scares the shit out of any musician. For daily use I turn to SourceTree for a more graphical and pleasant Git experience. SourceTree is free and hides most complex command line instructions behind a more useable interface. There will be a time however when you really will have to dive in to the nitty gritty and this post will also dive deep. Fortunately the latest version of SourceTree also understands the new LFS features.
Large File Storage
The first step will be to install Git LFS on top of Git. By the way SourceTree has embedded versions of Git and Git LFS that you can install alongside. I have no idea how powerful these embedded versions are compared to the stand alone versions. Then here the steps you need to take to activate the Large File Storage feature. Open a command line in the project folder where you created your Git repository and type (as marked in bold):
b2fab@STUDIO MINGW64 /d/Documents/Ableton/Goodbye Project (master)
$ git lfs install
Updated git hooks.
Git LFS initialized.
b2fab@STUDIO MINGW64 /d/Documents/Ableton/Goodbye Project (master)
$ git lfs track *.wav
Tracking "B2FAB - Goodbye ft Hanny (Mastered).wav"
Tracking "Goodbye (instrumental).wav"
Tracking "Goodbye ft Hanny (unmastered).wav"
Tracking "Goodbye ft Hanny.wav"
Tracking "Goodbye Hanny (FY).wav"
Tracking "Goodbye.concept.wav"
b2fab@STUDIO MINGW64 /d/Documents/Ableton/Goodbye Project (master)
$ git lfs track *.als
Tracking "Goodbye Hanny (Exp).als"
Tracking "Goodbye Hanny (FY).als"
Tracking "Goodbye Hanny (FYCD).als"
Tracking "Goodbye Hanny Beat.als"
Tracking "Goodbye.concept.als"
Tracking "Goodbye.Hanny.als"
Tracking "Goodbye.instrumental.als"
b2fab@STUDIO MINGW64 /d/Documents/Ableton/Goodbye Project (master)
$
As you can see the install statement just prepares the repository. The track statements marks large file types to be treated as LFS files. From that point you need to commit this change and its .gitattributes and you are good to go. If you want I can go live on Instagram or help you out.
