Source control for artists

Source control (also called version control) keeps every version of every file in a project on a shared server, so a team can work on the same game, see who changed what, and roll back mistakes. Epic describes it as "a backup and history of changes" and a way for "people to work together on their projects" (Unreal Engine 5.8 Documentation: Using Perforce as Source Control for Unreal…).

For artists, the main difference from programmers is the file type: code is text and can be merged, while most art files are binary.

#Why binary files need locking

Two programmers can edit the same text file and a merge tool combines their changes line by line. That does not work for a .blend, .psd, .uasset or .fbx. Epic is direct about Unreal assets: "These files are binary, so cannot be opened as text or merged in a text-based merge tool" (Unreal Engine 5.8 Documentation: Using Perforce as Source Control for Unreal…). The Git LFS project says the same of large binary files in general: conflicts are "very difficult to resolve" (Git LFS wiki: File Locking).

For this reason, teams lock binary files. Only the person holding the lock can submit a change; everyone else waits. In Unreal, checking out an asset "Checks out (locks) the asset for editing. This prevents other users from editing the asset at the same time" (Unreal Engine 5.8 Documentation: Source Control in Unreal Engine). Checking in uploads your changes "to the server and releasing the lock on the file" (Unreal Engine 5.8 Documentation: Using Perforce as Source Control for Unreal…).

#Core ideas

• Repository or depot: the server's copy of the whole project.
• Workspace or working copy: your local copy.
• Commit, submit or check in: send your changes to the server with a message.
• Lock or check out: reserve a file so nobody else can submit it.
• History: every previous version, so you can restore last Tuesday's model.

What goes in: source files (.blend, .ma, .spp, .psd), exported assets and engine assets. Unity reminds teams to "commit the .meta files to your repository", which store each asset's import settings (unity.com: Best practices for organizing your Unity…).

Folder moves need care. "If you move assets from one folder to another, many VCS will perceive this as just deleting one file and adding another", losing history; Unity says Plastic SCM (now Unity Version Control) "can handle file moves within Unity and preserve the history" (unity.com: Best practices for organizing your Unity…). Empty folders can also cause problems: "With Git and Perforce, empty folders are ignored by default" (unity.com: Best practices for organizing your Unity…). Settle the folder structure early.

#The main systems

See reference, review and presentation tools for the full tools table.

#Locking in Git LFS

Git was built for text, so locking is an add-on. You mark file types as lockable in .gitattributes, for example *.jpg filter=lfs diff=lfs merge=lfs -text lockable (Git LFS wiki: File Locking). Git LFS then makes those files read-only locally, which "prevents users from accidentally editing a file without locking it first" (Git LFS wiki: File Locking).

The commands (Git LFS wiki: File Locking):

• git lfs lock path/to/file registers the lock in your name on the server.
• git lfs locks lists current locks.
• git lfs unlock path/to/file releases it; --force removes someone else's lock, if the server allows it.

Locking needs server support, and "Git LFS won't halt your push if it cannot verify locked files" (Git LFS wiki: File Locking).

#Common mistakes

• Editing without locking. The second person to submit loses their work.
• Committing only exports. Keep the native source files too; see 3D file formats.
• Moving folders casually. History can break (unity.com: Best practices for organizing your Unity…).
• Forgetting Unity .meta files. Import settings and references are lost (unity.com: Best practices for organizing your Unity…).
• Holding locks overnight. Check in or release locks when you stop working.

#Further reading and watching