Compare and merge

All workspace members can compare accessible branches. Owner/Admin resolve conflicts and merge into an active target. The workspace and project must also be active for changes.

Compare source to target

1. Open Branches and select Source branch and Target branch.
2. Choose Compare source → target. Wait for ready.
3. Review the direction at the top. Filter by key name, locale, tag name, change type or Conflicts only. Lists are paginated. Tag name search also matches keys carrying that tag in the base, source or target; renamed tags remain discoverable by either name.
4. Read Base / Source / Target / Result for each field.

The base is shared history, not the current default branch. Source-only changes are proposed; target-only changes stay in the target. Matching results are not conflicts. Different changes to the same field require a decision. Text is never merged character by character.

Several equally valid common bases may exist after repeated or reverse merges. When those bases disagree and the current branches also differ, a conflict is shown rather than choosing an arbitrary base. Renames use logical key and tag identity. Independently created keys or tags with the same name are not assumed to be the same record.

Resolve conflicts

Choose Use source or Keep target. For values, tag names, key definitions and language configuration, Custom result accepts text or the displayed JSON structure. Value text is subject to the same Missing normalization, size and ICU checks as the editor.

Choose Save resolutions to validate the proposed result. A failed request preserves your local draft. Leaving with an unsaved draft asks for confirmation. Saved resolutions belong to that preview version; they are never silently reused for a new comparison.

Integrity issues identify invalid results: duplicate names, missing tags, tag limits, ICU contract mismatches, fallback cycles or inactive dependencies. Correct the conflicting choices or update the relevant branch and compare again. Restore an archived target key or activate an inactive target language before changing its content. The system does not secretly enable, change and disable content in one merge.

Archiving on one side while editing on the other requires review. A result cannot permanently remove keys or languages; use key archive or language inactivity. Tags cannot disappear while still assigned. File identities cannot point to conflicting keys.

Review and apply

Review the result cells and integrity issues, then choose Merge into target and confirm. Merge is disabled while conflicts, integrity errors or unsaved decisions remain. Only the reviewed target is changed; the source is preserved. Track the merge in Branch operations.

If either branch changes after the preview, application stops. Create a new comparison and review it again. A database or worker failure does not partially apply a merge: content, history, audit, ancestry and the completion record commit together. Retrying the same job cannot apply it twice. Processing operations cannot be cancelled after commit work starts.

History after merge

History shows the original actor and branch for inherited events. Shared history marks an event originating elsewhere. A source event rejected during resolution is historical evidence, not a claim that its value was written locally. The separate merge result records describe what was actually applied to the target. Events after a fork remain private to that branch’s history until a merge connects them.

Merging does not publish a release, select a runtime environment or deliver an SDK update.