Sync & conflicts

When you connect a Git repository, content can change in two places: the visual editor (app) and your Git repo. Doxbrix keeps both in sync and, in the rare case the same content changes in both at once, detects the conflict instead of silently overwriting.

How sync works

Doxbrix tracks a synced baseline for every page — the last version both sides agreed on. When something changes:

• App edit → committed back to Git, advancing the baseline.
• Git push → reflected in the app and on the live site, advancing the baseline.

As long as a page changes in only one place between syncs, there's nothing to resolve — the change simply propagates.

When conflicts happen

A conflict occurs only when the same page is edited in both the app and Git since the last sync. For example:

1. The synced baseline of guides/setup.mdx is version A.
2. A writer edits it in the app → version B.
3. Meanwhile, someone edits it in Git → version C.
4. Both diverge from A → conflict.

Detecting and resolving conflicts

Doxbrix flags a conflicting page rather than overwriting either side, and surfaces it for resolution in the app's Git Sync settings. Resolution follows the same model as a Git merge — keep one side, or reconcile both — and the agreed result becomes the new baseline on both sides. Locally, dxb status shows when your files have diverged from the cloud.

Avoiding conflicts

Conflicts are rare in practice, and easy to avoid:

Conflict scope

• Conflicts are detected per page (.mdx file), so unrelated edits never block each other.
• docs.json (navigation) is also tracked; structural conflicts are reconciled the same way.
• Pages edited in only one place always sync cleanly.

Attribution

When app edits are committed to Git, they're attributed to the author who made them in the editor — so your Git history reflects who wrote what, whether they used the app or Git.

Next steps