QA Workflow

Don't Commit Binaries to Source Control

For Unreal C++ projects, committing Binaries usually creates stale build problems, larger repos, and harder CI cleanup. Track source, config, content, and project files instead, then regenerate outputs locally or in CI.

ciautomationpackagingcommandlineplugin

I treat Unreal's Binaries folder as a build artifact, not source. If you're checking compiled outputs into source control for a normal C++ project, you're usually buying bigger syncs and stranger breakages than the convenience is worth. QA and CI both get cleaner when the repository only contains inputs, not generated outputs.

Overview

  • Know which Unreal folders are generated versus source of truth
  • Ignore Binaries, Intermediate, DerivedDataCache, and Saved
  • Keep source, config, content, and project descriptors under version control
  • Rebuild outputs locally or on the build agent using UBT/UAT

What should stay out of source control

Binaries contains compiled modules and platform outputs. Intermediate contains generated code and temporary build files. Saved and DerivedDataCache are machine-specific runtime and cache data, which are especially noisy in team environments.

plain text
Binaries/
Intermediate/
DerivedDataCache/
Saved/
.vs/
.idea/
*.VC.db
*.opensdf
*.sdf

# These are generated or machine-local outputs.
# Ignoring them prevents stale artifacts from polluting builds.

What should be committed

The files that matter are the ones needed to regenerate the build from scratch. For a typical Unreal project, that's your Source folder, Content, Config, Plugins, the .uproject file, and any custom Build.cs or Target.cs files. If a build machine can sync those and produce the game, your repo is in good shape.

  • Source/
  • Content/
  • Config/
  • Plugins/ including plugin source and content
  • *.uproject and any project-level build scripts

Regenerate and rebuild instead of syncing outputs

Once generated folders are ignored, your workflow should rebuild them consistently. I prefer a clean local command and the same command in CI so developers and build agents behave the same way. That makes broken packages easier to trace because you're not inheriting mystery artifacts from another machine.

powershell
Remove-Item -Recurse -Force .\Binaries, .\Intermediate, .\Saved -ErrorAction SilentlyContinue

& "C:\Program Files\Epic Games\UE_5.3\Engine\Build\BatchFiles\Build.bat" `
  MyGameEditor Win64 Development `
  "D:\Projects\MyGame\MyGame.uproject" `
  -WaitMutex -FromMsBuild

# Deleting generated folders first proves the project can rebuild from source-of-truth inputs only.

The one exception teams ask about

Some teams commit binaries for non-programmers who need editor access without a compiler toolchain. I still avoid it if possible and push prebuilt editor/game artifacts through a proper build distribution step instead. Artifacts belong in CI storage, not in the main branch history.

bash
RunUAT.bat BuildCookRun ^
  -project="D:\Projects\MyGame\MyGame.uproject" ^
  -platform=Win64 ^
  -clientconfig=Development ^
  -build -cook -stage -package -archive ^
  -archivedirectory="D:\Artifacts\MyGame"

REM Archive build outputs for testers and non-programmers instead of versioning Binaries.
If your repository already contains Binaries, remove them in one cleanup change and make sure everyone resyncs cleanly. Leaving some developers on old generated outputs is how you get the worst of both worlds.

This is a small source-control rule that pays back constantly in QA. Clean repos produce clean rebuilds, and clean rebuilds make automation trustworthy. If a file can be recreated by UnrealBuildTool or the editor, I don't want it versioned.

Source Reference

Inspired by a discussion on r/unrealengine (13 upvotes, 13 comments)

Related Tips