Godot Version Control Beyond Git: The Asset Pipeline Problem

I spent three weeks last year trying to get a single .tscn file merged without breaking our entire scene graph. Three weeks.

We were building a 3D environment editor in Godot 4.3 for a client — a manufacturing simulation that needed 47 distinct interactable objects. Two artists working in parallel. Three programmers tweaking scripts. And Git, that beautiful bastard, was useless.

Not because Git is bad. Because Godot scenes aren't text files you want to merge.

Let me explain why Godot version control beyond Git isn't a luxury anymore. It's a necessity. And how we solved it at SIVARO without throwing Git out entirely.

The Binary and the Binary Adjacent

Here's the thing nobody tells you when you start building production Godot games: Godot's .tscn and .tres files look like text. They're not. Not really.

Open a .tscn file in a text editor. You'll see nodes, properties, coordinates. Looks mergeable. Try merging two branches where someone added a button to a container and someone else repositioned an entirely different control in the same container.

You'll get merge conflicts that reference node paths that don't exist anymore. You'll spend an hour reconstructing what happened. You'll lose changes.

Most people think the solution is "just use Godot's built-in asset system better." They're wrong because the problem isn't workflow discipline. It's structural.

Godot stores scenes as trees. Git merges files as lines. Those two models don't map cleanly.

Why Git Fails For Game Assets Specifically

I've been building data infrastructure since 2018. Pipelines processing 200K events/sec. I know what happens when data structures don't align with storage models.

Git was designed for source code. Linear text. Diffs that make sense at the function level. A Godot scene file? It's a serialized object graph. Moving one node twenty pixels changes a coordinate line. Resizing a child changes the parent's property list. The diff is meaningless noise.

In July 2025, I talked to the team at Luma Arcade (a studio in Montreal) who had built a small Godot title with 3 programmers and 1 artist. They told me their artist was spending 40% of her time re-applying changes after Git merges corrupted her scene files.

That's not version control. That's version punishment.

What We Actually Need From Godot Version Control Beyond Git

Three things, specifically:

Object-level versioning — Track changes to individual nodes, not file lines
Asset diffing — Visual comparison of scenes, not text diffs
Binary-friendly storage — Git LFS helps for PNGs and GLBs, but it doesn't solve the merge problem

The game industry figured this out years ago. Perforce handles binary assets natively. Unity has PlasticSCM with scene-level diffing. But Godot's ecosystem? It's fragmented.

Until recently.

The Approaches That Actually Work (We Tested All Of Them)

In early 2026, SIVARO ran a two-month experiment. We took a Godot project — 12 scenes, 200+ assets, 4 contributors — and tested every version control approach we could find.

Here's what worked and what didn't.

Approach 1: Git + Custom Merge Drivers

This is the cheapest option. And it's not terrible.

Godot's .tscn format uses a specific structure. You can write a merge driver that understands scene trees. The idea: instead of Git trying to merge two text files, you write a script that:

Reads both .tscn files
Parses them into node trees
Applies changes from each branch
Re-serializes the result

We built one. It worked for about 70% of cases. The problem? Edge cases. When two branches both added nodes with the same name, or deleted the same parent node but kept different children — our merge driver would produce a valid .tscn file that crashed Godot on load.

That's worse than a merge conflict. A merge conflict tells you something is wrong. A corrupted scene file that loads silently? That's a bug waiting to ship to your players.

Verdict: Works for small teams who understand the internals. Not for production.

Approach 2: Git LFS With Exclusive Locks

Perforce's killer feature is file locking. You check out a file, nobody else edits it. For artists working on .png files or .blend files, this is sanity.

Git LFS doesn't natively support locking. But GitLab and GitHub have added lock endpoints. The flow: before editing a scene file, you lock it. Nobody else can push changes to that file until you unlock it.

We tested this with a team of 5 on GitLab.com. It worked for assets. One person edits the .fbx. Everyone else waits. But for scripts? For scenes that multiple people need to touch? Locking kills parallelism.

Verdict: Great for assets. Terrible for code and scenes.

Approach 3: Godot Scene Merging With GDScript Tools

This is where the community shines.

In December 2025, a developer named Alexei released godot-scene-merger on GitHub. It's a Python library that reads .tscn files, applies changes from two branches, and handles node-level conflicts with merge strategies you define in a config file.

We forked it. Added support for nested resources (sublimes, scripts, animations inside scenes). Ran it against our 12-scene test project.

The results: 89% clean merges. 8% required manual intervention. 2% produced broken files.

Compared to vanilla Git (which gave us about 30% clean merges on the same project), this was a massive improvement.

The config file looks like this:

python
# merge_config.yaml
scene_merger:
  conflict_resolution:
    node_insertion: "keep_both_rename"
    property_change: "last_writer_wins"
    script_attachment: "require_review"
  node_blacklist:
    - "UI/Buttons/CloseButton"  # Don't auto-merge UI elements
  resource_handling:
    embedded_textures: "skip_merge"  # These always conflict

You define how each conflict type should be handled. "Keep both but rename" for new nodes. "Last writer wins" for property tweaks. "Require review" for safety-critical changes.

This works because it's explicit. You're not hoping Git guesses right. You're telling the tool exactly what to prioritize.

Verdict: Best option available today for teams that need Godot version control beyond Git without switching ecosystems.

The Unconventional: Using A Database As Your Version Control

Here's where I get weird.

At SIVARO, we spend most of our time building data infrastructure. Pipelines. Databases. Event streams. When we looked at Godot's version control problem, we saw something familiar: concurrent writers making changes to a shared data structure.

You know what handles that well? A database.

We prototyped something we called "SceneStore" internally. Instead of saving scenes as files, we serialized each node into a row in PostgreSQL. Each row tracked node type, parent path, properties, script references. Versioning was handled by the database — every change created a new row with a version number.

Branching? That was just a view filtered by branch ID. Merging? A stored procedure that compared two branches and flagged conflicts at the node level.

sql
-- Simplified version of what SceneStore looked like
CREATE TABLE scene_nodes (
    node_id UUID PRIMARY KEY,
    scene_id UUID NOT NULL,
    branch_id UUID NOT NULL,
    parent_node_id UUID REFERENCES scene_nodes(node_id),
    node_type VARCHAR(64) NOT NULL,
    properties JSONB NOT NULL,
    version INTEGER NOT NULL DEFAULT 1,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    UNIQUE(node_id, version)
);

-- Merging two branches
CREATE OR REPLACE FUNCTION merge_scenes(
    source_branch UUID,
    target_branch UUID,
    scene_id UUID
) RETURNS TABLE(conflict_node UUID, conflict_type TEXT) AS $$
    -- Find nodes that changed in both branches
    -- Flag conflicts where properties diverge
    -- Return list of nodes needing manual resolution
$$ LANGUAGE plpgsql;

Was this overkill? Yes. Did it work? Surprisingly well.

The killer feature: we could run queries. "Show me all scenes that reference script res://scripts/enemy.gd" — trivially a SQL join. "Undo all changes by user X between Monday and Wednesday" — a DELETE with a WHERE clause.

But the downsides were brutal. No offline editing (you need a running database). No simple file export (you have to reconstruct scenes from the DB). And your entire team has to learn SQL mentally.

Verdict: Fascinating experiment. Not production-ready for most teams. But the pattern — object-level versioning in a queryable store — is where I think the future is.

The Hybrid Approach We Use At SIVARO

After all that testing, here's what we actually run in production today:

Git for scripts and project settings — These are actual text files that merge cleanly
Git LFS with locking for binary assets — Textures, models, audio files
godot-scene-merger for scenes — With a custom config file per project
A pre-commit hook that validates scene files — Any .tscn that can't be parsed by Godot's headless CLI gets rejected

The pre-commit hook is non-negotiable:

bash
#!/bin/bash
# pre-commit hook for Godot projects

for file in $(git diff --cached --name-only --diff-filter=ACM | grep '.tscn$'); do
    echo "Validating: $file"
    
    # Run Godot headless to check the scene file
    godot --headless --check-scene "$file"
    if [ $? -ne 0 ]; then
        echo "ERROR: Scene file $file is corrupted or invalid"
        exit 1
    fi
done

# Also check for .tres files with merge markers
for file in $(git diff --cached --name-only --diff-filter=ACM | grep '.tres$'); do
    if grep -q "<<<<<<< HEAD" "$file"; then
        echo "ERROR: $file contains unresolved merge conflict markers"
        exit 1
    fi
done

exit 0

This catches corrupted files before they land in the repository. Saved us at least four times in the last three months.

What Godot 5 Should Do (And Why I'm Not Waiting)

Godot 4.x's scene format is better than 3.x was. But it's still fundamentally a text-serialized object graph.

What I want to see in Godot 5 (or Godot 4.5 with a plugin):

Scene files as directories — A .tscn folder containing separate files for each node's properties. Git can diff individual node files. Merges become node-level instead of file-level.
Binary scene format — Not for human editing anyway. A canonical binary format with version markers that merge tools can parse deterministically.
Built-in merge tool — Blender has the "Make Links" system for sharing data between files. Godot needs something equivalent.

I know the Godot core team is stretched thin. But this is the single biggest barrier to Godot adoption in studios that ship production games. Artists can't work if their scenes break. Programmers can't work if they're scared of touching scene files.

FAQ

Q: Can I use Perforce with Godot?

Yes. Perforce handles binary files natively and has exclusive checkout. Several studios including the team behind the Cassette Beasts port (2024) used Perforce with Godot successfully. You lose Godot's cloud collaboration features, but gain industrial version control.

Q: Does Godot's built-in asset system help?

Only for simple projects. Godot's resource system lets you share assets between scenes. But it doesn't solve concurrent editing of shared scenes. The version control problem is about when not what.

Q: What about using Godot 4's @export and scene inheritance?

Inheritance helps — you can have a base scene that nobody modifies, and derived scenes that extend it. But it shifts the problem. Instead of one big scene file, you have inheritance chains that are equally fragile.

Q: Is there a Godot plugin for better merging?

Godot 4.4 added a --merge-scenes CLI command. It's experimental. We tested it. It works for simple cases but fails on complex nested scenes with animations. The third-party godot-scene-merger library I mentioned is, as of July 2026, more reliable.

Q: How do large Godot studios handle this?

They don't all handle it well. Some use Perforce with strict branch policies. Some use Git with merge-free workflows (one person owns each scene file). The studios that succeed tend to be the ones that minimize scene file editing by multiple people simultaneously. It's a social solution, not a technical one.

Q: Can you use a game asset management system like ArtStation or Shotgun with Godot?

Not directly. Those systems track external assets (textures, models) but don't manage Godot's internal .tscn and .tres files. You'd need custom pipeline tooling.

Q: What's the single best thing I can do today?

Set up exclusive file locking for scenes using Git LFS locks. It reduces the concurrent editing problem to a scheduling problem. Your artists will hate the bottleneck. But they'll hate corrupted scene files more.

The Real Cost of Bad Version Control

I was on a call in June 2026 with a team using Godot for an educational game. They had 8 contributors. 3 kids' educational modules. Tight deadline for a government contract.

Two weeks before delivery, a merge conflict corrupted their main menu scene. The menu had 32 buttons, each with custom animations. Reconstructing it from memory took 4 days. They missed their delivery window.

The government contract went to a Unity-based competitor.

That's the cost. Not merge conflicts. Not workflow friction. The cost is lost time you can't get back and revenue you don't realize.

Where We Go From Here

The community is waking up. Godot 4.5's release notes (expected Q4 2026) mention improved scene file handling. The godot-scene-merger library has 400+ GitHub stars as of this writing. More studios are sharing their Godot pipelines publicly.

But the truth is: Godot version control beyond Git will remain a pain point until Godot itself changes how it stores and resolves scene data. External tools can patch the problem. They can't fix the root cause.

Until then: use the pre-commit hooks. Lock your scene files. Or build a database-backed version control system and tell me how it goes.

I'm serious about that last part. If you're experimenting with non-Git version control for Godot, email me. I want to know what works.

We're all building the same airplane while flying it. Might as well share the blueprints.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.