Skip to main content

Conflict Resolution

Conflicts occur when both the local app and the remote repository have changes to the same models. This can happen during a pull operation or when creating a pull request. Flowable Design provides a guided conflict resolution UI to help you resolve these situations.

When Conflicts Occur​

A conflict is detected when:

  • You pull remote changes that modify a model you have also modified locally.
  • A pull request involves changes on both the source and target branches that affect the same model.
  • Two team members edit the same model on different branches and one tries to merge into the other.

Conflict Detection​

When a pull or PR operation encounters conflicting changes, Design pauses the operation and presents the conflicting models. Each conflicting model shows:

  • The local version (your changes).
  • The remote version (the incoming changes from the repository).
  • A visual diff highlighting the differences between both versions.

Resolution Strategies​

For each conflicting model, you can choose one of the following resolution strategies:

Accept Local Version​

Keep your local changes and discard the remote changes for this model. This is appropriate when:

  • Your local changes are more recent and correct.
  • The remote changes are no longer needed.
  • You have already incorporated the intent of the remote changes in your local version.

Accept Remote Version​

Discard your local changes and accept the remote version for this model. This is appropriate when:

  • The remote changes are more important or correct.
  • Your local changes can be reapplied later.
  • You want to start fresh from the remote state.

Resolving Conflicts Step by Step​

During a Pull Operation​

  1. Initiate a Pull from the Git panel.
  2. If conflicts are detected, the pull pauses and displays the conflict resolution UI.
  3. For each conflicting model:
    • Review the visual diff showing your local version alongside the remote version.
    • Choose to accept the local or remote version.
  4. After resolving all conflicts, confirm the resolution.
  5. The pull completes with your chosen resolutions applied.

During Pull Request Creation​

  1. Initiate Create PR from the Git panel.
  2. Design generates a preview of the PR, including any conflicts between the source and target branches.
  3. If conflicts exist:
    • Review each conflicting model with its diff.
    • Choose the resolution for each conflict.
  4. After resolving all conflicts, proceed with creating the pull request.

Visual Diffs in Conflict Resolution​

The conflict resolution UI uses the same visual diff capabilities as the Compare and Diff feature. This means you get model-type-specific diffs:

  • BPMN processes show diagram-level differences with changed elements highlighted.
  • Forms show field-level structural differences.
  • Data dictionaries show attribute-level differences.
  • Other model types show JSON-based diffs.

These visual diffs make it easier to understand exactly what changed on each side before choosing a resolution.

Best Practices​

tip

Pull frequently. The more often you pull remote changes, the smaller the divergence between local and remote versions, and the less likely you are to encounter conflicts. Frequent pulls lead to simpler, more manageable conflicts when they do occur.

  • Communicate with your team about which models each person is working on. Coordinating who edits which models reduces the chance of conflicting changes.
  • Use feature branches for larger changes. This isolates your work and limits conflicts to the merge point, where they can be reviewed carefully through a pull request.
  • Commit early and often. Small, focused commits are easier to understand and resolve when conflicts arise.