Version Control¶

A Doriax project is designed to be committed. Scenes, bundles, scripts, assets and project.yaml are the game, and every one of them is text or an ordinary asset file.

What the editor keeps out of the repository matters just as much. Your open tabs, the place you left each viewport camera, your compiler path and the build tree are yours alone — committing them means a diff every time anyone opens the editor, and a conflict every time two people do. All of it goes under .doriax/, which is not committed.

What to commit¶

CMakeLists.txt is generated from project.yaml and your scripts every time you press Play, so there is nothing in it to preserve. It also holds no path belonging to your machine: asset and Lua roots resolve from ${PROJECT_ROOT}, and the paths that are machine-specific — the shader cache, the engine library — come from .doriax/LocalPaths.cmake, which the editor rewrites and which is not committed. See C++ Build Setup.

Inside .doriax¶

The editor recreates all of it, so a fresh clone needs nothing but the editor opened once. Deleting .doriax/ costs you the editor layout you had, a rebuild, and the FBX conversions, never project content.

The generated ignore rules¶

With Version Control Files enabled in Project Settings → General — the default — the editor keeps .gitignore and .gitattributes written at the project root and refreshes them whenever the project is saved.

.gitignore covers the table above. .gitattributes normalizes line endings so that scenes and project.yaml diff and merge the same way on every machine, and marks the common asset formats binary:

* text=auto eol=lf

*.scene   text eol=lf
*.bundle  text eol=lf
*.yaml    text eol=lf
...
*.png     binary
*.glb     binary

A file the editor did not generate is never replaced. Both files start with a # Generated by Doriax Editor. marker line, and the editor only rewrites one that still carries it — so a .gitignore you wrote or extended yourself is left alone, and you can turn the setting off to stop the editor touching them at all.

Git in the editor¶

With Version Control Files on and the project inside a Git repository, the editor shows where your work stands, as VS Code does:

• Footer — the branch at the far left, followed by * when there are uncommitted changes, + when some of them are staged, and ! during a merge or rebase or with unresolved conflicts. A detached HEAD shows its tag, or the short commit. When the branch tracks a remote one, the commits behind and ahead follow, as 1↓ 2↑. Hover them for the details.
• Code Editor — the lines that differ from the staged version of the file are marked in the gutter, with the change shown when you point at a mark. See Code Editor — Changed lines.

The editor reads the repository with the git command, so Git has to be installed and on the PATH. It never stages, commits or switches branches; that stays in your Git tool, and the editor picks up what it did within a second or two. While the editor is in the background it only watches for staging, commits and checkouts, and it reads the rest again when you come back to it.

Working as a team¶

Scenes and project.yaml are line-based YAML, so Git merges them like any other text file. Two things make that reliable:

• Scene ids are unique across branches. Each scene carries an id that startSceneId and child scene references point at. Ids are drawn at random rather than counted up, so two people adding a scene on separate branches do not collide.
• Nothing per-user is in the shared files. Moving the camera, opening a tab or changing the terrain brush never marks project.yaml as modified.

Scenes still merge best when they are small. Splitting gameplay areas into separate scenes and composing them with child scene references keeps each file focused — see Scene files.

If a scene file is missing from your checkout — a branch you have not fetched, or an asset still uploading — the editor keeps its entry in project.yaml and warns instead of quietly dropping the scene from the project. Saving the project will not remove it for everyone else.

A scene keeps the parts of each model as it was saved. After replacing an FBX, open every scene that uses it so its models reload, save them, and commit those scenes with the FBX. An export, on any machine, stops at a scene saved with an older version of an FBX it uses — see Export — FBX models.

Migrating an existing project¶

Projects created before the split kept the camera, tabs and terrain brush in project.yaml. Opening one in a current editor copies those values into .doriax/user/workspace.yaml, so nothing is lost; the keys stay in project.yaml until you save the project, which is the only thing that rewrites it.

Two one-time steps for a repository that already has history:

1. CMakeLists.txt is usually already committed. Stop tracking it once:

   git rm --cached CMakeLists.txt
   

2. If the project has no .gitignore yet, open Project → Project Settings, confirm Version Control Files is on, and press OK to write it.

The first commit after that shows project.yaml shrinking to the settings that describe the game, and one extra newline at the end of each scene file. Both are expected and happen only once.