AKA Oh god, not Git.

Have great respect for source control. It’s absolutely necessary to collaborate with a team. Unless you’re going to only give sound files to a team and have no interaction with the project itself, you’ll want to at least know the basics of how to push and pull to/from a Git repository using a Git client. Currently GitHub’s client is very straightforward but only works if the team is using GitHub.

But always be cautious with it. A badly coordinated push or weird merge can ruin a project or at least make it unplayable while everyone scrambles to fix it. It’s happened to multiple projects I’ve worked on. That sort of thing isn’t likely to be as much of an issue in normal life (changes can be rolled back or discarded and people are usually more careful about where they work). Game jams, especially one or two day jams like Global Game Jam, are at greater risk.

So how do you as the audio person decrease the chances of Git disaster?

First: Make sure the repository knows what changes to ignore and what not to ignore. This is especially true with audio middleware which will need extra files added to that list. FMOD, for example has a list of extra files to be added to the .gitignore file. If those aren’t added, you’ll end up with a whole lot of unnecessary merge conflicts and annoyed programmers.

Edit: Maximilian Poirier has a comprehensive walkthrough of what should be included in source control for Wwise projects.

From my experience, I’ll suggest keeping an eye on what files the client software you’re using ignores by default. When I last used Sourcetree with Wwise, it ignored necessary files for the integration to work properly. It was maddening.

Next: Practice discipline with the files you edit and push. While merging code is possible in Git, merging other files means choosing between whose version of that file is correct or not.

That means communicating with the rest of the team about what you’re working on to avoid those conflicts.

It means keeping an eye on all files that might’ve been changed since you last pushed your changes and make sure that only the files that you want to be updated or added in the repository are pushed. Engines can update files that don’t need to be changed or pushed to the repository. It’s annoying.

Finally: Limit the amount of people who push to the repository. I would suggest that all audio pushes to the main repo go through one person. If multiple people are editing events in middleware, I suggest using a repo specifically dedicated to the audio project itself, hosted completely separately from the main project’s repo.

From there, the person who pushes to the main repo can build banks. That keeps all changes to the sound updated with limited files changed in the main repository.

That’s actually pretty easy in FMOD Studio, enough that I’m genuinely recommending it.