Conflux

A prefab merge tool for Unity. Resolve three-way conflicts by what a prefab means, not what its text looks like, one property at a time.

The window

Three synchronized panels

The three-panel Conflux window with a real prefab conflict open

Ours, Merged and Theirs share one row plan. Selection, expansion and scrolling stay in step. Values are shown rather than edited: one enters the merge by picking a side.

The diff

Semantic three-way diff

Status markers on hierarchy rows across all three panels, with the toolbar tally above them

Every GameObject, component and property is classified against the common ancestor: added, removed, changed on one side, changed the same way on both, or a real clash. Only the clashes need your input. The rest merge on their own.

The pickers

As coarse or as fine as you want

Inspector rows showing each side's value and the picker that chooses between them

One arrow takes a whole GameObject or component from one side; every diffing row also carries its own picker. Narrower wins over wider, so a property refined after taking a branch keeps its refinement. Each picker fills like a progress bar as its scope settles.

The preview

A merged preview you can open

The merged prefab open in Unity's Prefab Mode below the Conflux window

The merged result is rebuilt after every decision and opens in Unity's Prefab Mode. It is the actual prefab, built by the same APIs that will write it when you hit Apply. It refreshes as you decide, and you can frame the part you care about and watch it settle.

Structure

Structure gets its own decisions

Order, reparent and manual arrange controls on the Merged panel

Sibling order, component order and reparenting are tracked apart from values, so a reorder on one branch and an edit on the other can both survive. When neither side's order is what you want, arrange it yourself in the Merged panel.

Every merge conflict on a prefab is the same afternoon. Git hands you two walls of YAML it can't reconcile, your merge tool offers to take one side whole, and whichever one you pick throws away work somebody did. Sometimes the file won't open afterwards. The worse case is when it opens fine and the prefab is quietly broken in a way nobody catches for a week.

None of that is Git's fault. What a prefab actually contains is component types, references and nested overrides, and none of it survives being compared as lines of text. This tool asks a different question: parse all three sides into a real object model, compare them field by field, and let Unity's own APIs rebuild the result.

Start to finish

How a merge goes

  1. Start a merge that produces conflicts on .prefab files under Assets/.
  2. Open Tools › Conflux › Merge. Conflicted prefabs are listed down the left. Open starts fresh; Resume restores your decisions from last time.
  3. Resolve. Per entity from the hierarchy rows, per property from the inspector.
  4. Follow the toolbar tally, narrow the panels to the kinds you care about with the filter beside it, and jump between unresolved items with ▲ / ▼.
  5. Check the result with Preview, which opens the merged prefab in Prefab Mode.
  6. Apply writes the merged prefab over the conflicted file, then reads it back and checks it against the result you approved.

Apply writes the file and stops. No git add, no p4 resolve, no svn resolved. Marking a conflict resolved is your call to make once you've looked at the result.

Under the hood

Safety, variants and everything else

It backs up before it overwrites

Before it overwrites anything, Apply spells out what will change. It also saves the prefab as it stood on your side before the merge, in ConfluxBackups/ or wherever you point it. If the backup can't be written, nothing is overwritten.

It checks what it wrote

After writing, it reads the file back through Unity's loader and compares it with the result you approved: every object, component, value and reference. A difference is named object by object. Identity is part of that check, so quietly renumbered fileIDs are caught before they break every variant and scene reference.

Variants and nested prefabs

Conflux reads the base and shows the inherited hierarchy inline, so a variant looks like the prefab does in the Inspector. Overrides and deletions on inherited objects are tracked per side. Unpacked instances are refused with a warning rather than silently merged wrong.

Keep both

Where both branches appended to the same list, take both. It starts from Theirs, appends the Ours entries that aren't already present, keeps the order and skips duplicates. References, strings and lists of your own structs all work.

Whatever you version with

Git, Subversion, Mercurial, Perforce and Plastic SCM. Detection is automatic, and everything you see is identical either way. It can also serve as an external merge tool for any of the five.

Show only what you're looking for

The tally beside the toolbar is also the filter. Uncheck a kind and its rows leave all three panels together. Nothing is hidden from the write: the outstanding count still counts all of it, and Apply is still blocked by what you can't see.

Built for a whole branch merge

The sidebar counts how many of the listed conflicts hold a merged result, and applying one opens the next, so seven files isn't seven round trips.

Sample conflicts, built in

Fifteen hand-built scenarios covering value clashes, identical edits, modify/delete, reorders, reparents, nested overrides, variants and more. They open through the same pipeline a real conflict does.

Before you commit

Limitations

A variant needs its base resolved first

If the base is conflicted too, Conflux refuses to open the variant rather than letting you work through it and hit a wall at Apply.

No apply all

Deliberately absent. Every write asks first and says what it will change. Overwriting prefabs in someone's repository is not a thing to do behind a single confirmation.

Specs

Technical details

Built for small and very large prefabs

Every panel is version-gated and cached, the hierarchies draw only the rows on screen, and the inspector renders only the selected object. A tiny prefab and one with thousands of objects both stay responsive; on the largest, the live preview steps aside automatically so each decision is instant.

Prefabs, scenes in progress

Prefab (.prefab) merges are the intended scope. Scene (.unity) support is a work in progress: scenes have many roots plus settings singletons that would diff happily and then never rebuild.

Your custom editors, drawn

A component with your own [CustomEditor] shows that inspector, read-only, above its rows, so it is recognisable at a glance. The rows underneath still carry every per-property decision, and the block folds away when you would rather just merge.

Git, SVN, Mercurial, Perforce, Plastic

Conflicts are read from whichever of the five you use, through the version control CLI already on your machine. Plastic SCM points its external merge tool at Conflux once; the other four are detected automatically.

Windows, macOS and Linux

Paths and processes go through the platform's own APIs, with no hardcoded separators or Windows-specific calls, so the same editor tool runs on all three.

Unity 2021.2+

PrefabStageUtility moved out of the Experimental namespace in 2021.2, which sets the floor. The rest of the API surface has been stable since 2018.3.

Editor-only

Nothing ships in a build and nothing runs at runtime. No dependencies. It talks to the version control CLI already on your machine.

Full C# source, no DLLs

No C# 8+ syntax, so it keeps compiling on the language versions that came with older editors. Nothing in it is a black box.

Tested

An EditMode suite covers parsing, diffing and resolution as plain data, the merged result as real Unity objects, and the written file read back and compared.

Render pipeline agnostic

Built-in, URP and HDRP behave the same, since the tool draws editor UI and never touches rendering.

Localized for multiple languages, more by request

English, Portuguese, Spanish and French, each picked from Preferences and named in its own language. You can add your own freely: a translation is one JSON file named by its language code, dropped in the localization folder, and it appears in the list. Any key it omits falls back to English, so a partial one is usable from the first line.