Merging Branches

Merging combines the changes from one branch (the source) into another branch (the target). Conflicts are reviewed and resolved before the merge completes, so Creators retain full control over what ends up in the result.

Note: Whether a published version can be the target depends on the merge mode. In conflict-resolution mode the target must be a branch, because the merge writes into it and published versions are read-only. In accept-changes mode a published version can be the target, because the merge writes its result to a new branch instead. In neither mode can both sides be published versions.

Merge Modes

The merge workflow resolves differences at one of two levels, depending on environment settings. Both levels complete a merge.

• Conflict resolution: Work through each changed module and resolve its differences component by component. The merge writes the result into the target branch. The steps below cover this mode.
• Accept changes: Review every changed module and workflow, then accept the ones to take from the source. Anything left unaccepted keeps the target's version. Name an output branch, and the merge writes its result there instead of into the target, creating a third branch that synthesizes two independent lines of work and leaves the originals in place.

The Unqork platform determines which mode is active automatically based on environment configuration.

Note: In accept-changes mode, neither original branch receives the merged content, but any unsaved changes on both are committed before the merge runs. Start the merge only when ready to commit both sides.

Step 1: Select Branches

To begin a merge, open the merge workflow from either of the following locations:

• Checkout pill: In the module toolbar, click the checkout pill and select Start a Merge....

• Application row menu: Right-click a versioned application in the Explorer panel and select Start a Merge....

When the merge workflow opens, a persistent bar at the top displays Source and Target dropdowns. Select a source (the branch or version with incoming changes) and a target (the branch or version to receive the changes). Use the swap button to reverse the direction. The conflict resolution view loads automatically once a valid pair is selected.

Note: The source and target cannot be the same branch. At least one side must be a branch, in either mode. Two published versions cannot be merged.

Step 2: Resolve Conflicts

The conflict resolution step displays all modules that have differences between the source and target branches.

Summary Bar

A summary bar at the top of the merge surface displays the scope of the merge:

• Tiles: Modules impacted (with component count), total conflicts, total changes (with auto-merged count), and dependencies.
• Progress bar: Displays how many conflicts are resolved out of the total.
• Compared readout: Displays when the comparison was last run and how many changes and unresolved conflicts remain.

Use the All / Conflicts / Changes scope tabs to filter the view. The selected scope narrows both the module stack and the jump-navigation rail together.

Module Stack

Modules with differences display as collapsible sections in a scrollable stack. Each section contains the components with changes for that module. Conflict-bearing sections default to expanded. Change-only sections default to collapsed. Sections with more than 100 conflicts start folded to preserve performance.

To navigate directly to a section, use the jump-navigation rail to the side of the stack.

Resolving Conflicts

Each component displays its changes as rows in a table. Each row shows the conflicting values side by side, with columns headed by the branch names. A Status chip shows the state of each row:

• Pick One: The conflict has not been resolved yet.
• Approved: A side has been selected.
• Auto-approved: The platform resolved the row automatically with no action needed.

To resolve a conflict, click the value cell for the side to keep. Clicking a cell tints it and marks it as the selected side, changing the row status to Approved.

For more complex differences, adjust the configuration manually to preserve what is needed from both sides.

Bulk Resolution

To resolve all remaining conflicts at once, click the (ellipsis) in the merge bar and select Resolve all with source or Resolve all with target. If any conflicts have already been manually resolved, a confirmation dialog displays before overwriting them.

Data Workflow Modules

For Data Workflow modules, the conflict resolution view displays three synchronized canvases side by side:

• Source: The incoming state from the source branch.
• Target: The existing state from the target branch.
• Merged: A preview of the merged result based on the resolution choices made.

Select nodes and links in the Source or Target canvas to apply them to the Merged canvas.

Step 3: Complete the Merge

When all conflicts are resolved, click Merge in the merge bar. The Complete merge dialog opens and validates the resolution automatically.

When validation passes, select a Merge strategy:

• Update target: Merges source changes directly into the target branch.
• Create new branch: Creates a new branch with the merged result. Enter a name for the new branch.

To remove the source branch after merging, select Delete source branch after merging.

If a Warnings alert displays, the merge detected orphaned components: components the platform cannot place in the existing layout structure. The platform places them in a new panel at the top of the affected module. Select I acknowledge these warnings and want to proceed to continue.

Click Merge in the dialog to run the merge. A progress indicator displays while the merge runs. When it finishes, the platform navigates back to the application.

Note: If the merge placed orphaned components in a new panel, reorganize them into the correct layout and delete the automatically created panel after reviewing the result.