As edits are made to a version, the versions begin to differ from one another. After a named version is created, all edits are tracked in the default version and the named version. Edits in the default version can include edits posted by other named versions.
Once you finish editing a named version, you can perform the reconcile and post processes to merge your edits. The process of retrieving any changes from the default version and merging them with your version is called reconcile. Next, you can send the changes you've made to the default version using the post process. With branch versioning, you always reconcile and post using the default version as the target version.
Conflicts are discovered when the named version is reconciled with the default version. When conflicts are discovered during the reconcile operation, they are initially resolved in favor of the edit version. You receive a prompt, asking if you want to review conflicts using the Conflicts view. Here, you can review them one at a time and, if necessary, make changes. For example, you can use the Conflicts view to replace with the target version or use the editing tools to modify the feature in conflict in another way.
The reconcile process updates only the edit version so that ArcGIS Pro can check for conflicts; it does not merge changes into the target version. Once you finish reconciling and reviewing conflicts, you complete the merging process by posting your changes to the target version.
Note:
This topic describes the reconcile and post processes using the Versioning tab. You can also reconcile and post versions using the Reconcile Versions geoprocessing tool or the Reconcile/Post button
on the Versions tab when you are in the Versions view.Reconcile process
When you're working in a branch version, reconciling with the default version detects conflicts between it and the named version to which you are currently connected. A warning is returned if you attempt to reconcile and there are conflicts that are not marked as reviewed. With branch versioning, you can only reconcile with the default version. You cannot reconcile with another named version.
Learn more about version access
When accessing branch versioned data sources as web feature layers, you can use the Reconcile and Post tools. To start the reconcile process, click the Reconcile button on the Versioning tab. The Reconcile dialog box appears. Reconciling versions for branch versioned datasets uses the following conditions:
- Conflicts can be defined by object or by attribute.
- Conflicts are always resolved in favor of the edit version.
The undo and discard operations cannot be used to revert changes made after a reconcile operation is completed for branch versioned data.
If conflicts exist, you can review them in the Conflicts view.
Review conflicts in the Conflicts view
If conflicts are detected during the reconcile process, you can review them in the Conflicts view 
. The view can be docked anywhere in the app or positioned as a floating window. This allows you to interact with a map view at the same time to provide context and further explore the data. The Conflicts view contains all the conflict classes and their features or rows in conflict. The conflict classes represent the web feature layers in conflict for the entire service.
The Conflicts view allows you to do the following:
- Determine the fields or rows in conflict.
- View conflicts.
- Mark conflicts as reviewed or not reviewed.
- Resolve conflicts by designating the representation to use to replace features or attributes.
Conflicts occur in the following instances:
- The same feature updates in both the current edit version and the target version.
- The same feature updates in one version and is deleted in the other.
- A topologically related feature or relationship class is modified in the current edit version and the target version.
If conflicts exist in a branch version, ArcGIS Pro resolves them in favor of the edit version.
In branch versioning, conflicts are persisted in a system-owned GDB_CONFLICTS table. This allows you to manage conflicts over multiple edit sessions, review and resolve conflicts, and leave and come back later to continue. A second reconcile operation cleans the conflicts table and repopulates it with new conflicts that occurred since the last reconcile. This means that you may lose your history of conflict resolutions if a second reconcile is performed.
Determine the fields or rows in conflict
All conflict classes and features are shown in the list box on the upper left side of the Conflicts view. This list shows the total number of conflicts for web feature layers for the entire service.
Click an object drop-down arrow to see the conflicts for each feature. These are separated into the following categories:
- Update-Delete—The feature was updated in the current version and deleted in the target version.
- Delete-Update—The feature was deleted in the current version and updated in the target version.
- Update-Update—The feature was updated in both the current and target versions.
When you select an individual feature's ObjectID in the list, the fields and attributes in the Current, Target, and Common Ancestor versions of the feature appear in the information grid on the right side of the Conflicts view.
Having the attributes and values for all representations of a feature in conflict allows you to see how the attribute values differ across versions and helps you determine the representation of the data to preserve.
- Current—Represents the current state of the features and attributes in the named version. This includes any edits that you made.
- Target—Represents the features and its attributes in the target version.
- Common ancestor—Represents the features and attributes when the version was initially created or at the time of the last reconcile operation.
A red indicator to the left of the row identifies a conflict. For example, if the feature's geometry was edited in each version, a red indicator appears next to the Shape field.
If other attribute fields are in conflict, a red indicator appears to the left of the row. If a feature has been deleted in either version, <Deleted> appears for that version's attribute value.
Two buttons at the bottom of the dialog box allow you to switch between viewing all the fields or viewing only those fields that are in conflict.
Mark as reviewed or not reviewed
Once you determine the fields or rows in conflict, you can mark a feature as reviewed. You can keep track of the features in the list you have reviewed because those marked as reviewed no longer appear in bold.
To come back to a feature conflict later, right-click the ObjectID in the conflicts list and click Mark as not reviewed. This causes the feature to appear in bold again.
If you check the Filter Reviewed Conflicts check box at the top of the view, you can filter the list to show only conflicts that have not been reviewed.
With branch versioning, you can also add a review note. Right-click a feature, click Add Review Note, and type text in the Add Review Note text box. To edit an existing review note, right-click a feature and click Edit Review Note.
Note:
Review notes are cleared on the next reconcile and post operation.
Resolve conflicts
When you resolve conflicts, you are deciding which representation of the features and attributes you want to keep. After the reconcile operation, you can use the Conflicts view to specify the representation to keep. Keep in mind that using the replacement options in the Conflicts view is the same as performing an edit operation.
In the Differences list, right-click the version, dataset, feature, or attribute and select one of the following replacement options:
- Replace With Current Version
- Replace With Target Version
- Replace With Common Ancestor Version
The following are different levels in which you can use the replacement options to resolve conflicts:
- Attribute replacement
This occurs at the field level. If there are conflicts in attributes, you can replace only the attribute value in the current version with one from either the current, target, or common ancestor representation. To do so, right-click the attribute in conflict and click the option on the menu.
- Feature replacement
This occurs at the row level. You can replace an entire feature with the representation of the feature in the current, target, or common ancestor version. This means the fields in conflict are replaced.
- Class-level replacement
You can replace the current representation of the entire feature class with the current, target, or common ancestor version representation to resolve the conflict. This replaces all the conflicting features and attributes at once, allowing you to quickly update and replace conflicting features. If there are multiple features in the Differences list, all of them are replaced with the version you choose.
To choose a class-level replacement option, right-click the feature class name in the Differences list and click the version you want to use.
- Complete replacement
This occurs at the root level. This option replaces all conflicting features and feature classes in the list with the representation designated. If you have multiple feature classes and objects in conflict, all of them are replaced with the version you choose.
Right-click the version and connection information at the top of the Differences list and click the version you want to use to replace all conflicts.
Field-level conflict filtering
In some cases, you may want edits that were applied to a field or set of fields to remain when conflicts are detected during reconciliation. The following are examples of when you may want to filter out conflicts detected on a field when reconciling:
- A batch update is performed on a field in different versions.
- Information is written to a field based on the edits performed in the version.
You can use the Add Field Conflict Filter tool to define the set of fields to filter from conflicts. A field conflict filter allows you to tag a field or set of fields in a feature class to filter them from conflict detection. This is only applicable when you are defining conflicts by attribute.
Note:
After applying a field conflict filter to a field or set of fields, when you reconcile, conflicts are not identified if only the fields on which the filter is set were edited. If other nonfiltered fields were edited, and conflicts exist in the target version for those fields, when you reconcile, all fields (filtered and nonfiltered) in conflict are identified in the Conflict view.
Branch versioned data is always reconciled with conflicts in favor of the edit version; fields with a conflict filter contain the value from the edit version.
You can use the Remove Field Conflict Filter tool to remove these conflict filters from the fields.
Note:
Services with branch versioned data must be restarted to pick up changes from the Add Field Conflict Filter or Remove Field Conflict Filter tools.
You can use the ListFieldConflictFilters Python function to identify when a feature class or table has conflict filters defined.
Resolve conflicts with attribute rules
Attribute rules improve the editing experience and data integrity for geodatabase datasets. When performing a reconcile in which conflicts are defined by attribute (column), immediate calculation or constraint rules are evaluated for features that have been updated in both the default and the version being reconciled. If a constraint rule is violated during this process, the merge will not occur, the feature will be promoted to an Update-Update conflict and can be reviewed in the Conflicts view.
Resolve conflicts with relationship classes
Relationship classes can be used to help enforce referential integrity between related objects. If branch versioned data sources participate in a relationship class, the reconcile process evaluates this data for referential integrity. If referential integrity is violated, participating features are reported as conflicts and can be reviewed in the Conflicts view.
Deleting a feature from an origin relationship class may trigger a message to delete a feature from the destination relationship class. Therefore, be aware of the ramifications of simply replacing conflicts involving feature classes that participate in relationship classes.
The following is an example of a conflict that can arise between relationship classes:
- You update the Origin Class Primary field, breaking the relationship in version A.
- At the same time, you update the destination class-related feature in version B.
- Since the destination class is dependent on the origin class, a conflict is detected when you reconcile the versions.
Another example is the following:
- In your electric utilities feature dataset, you delete a pole that has a relationship to a transformer, causing the related transformer to also be deleted.
- In another edit session occurring at the same time, an editor alters the attributes of the transformer you had just caused to be deleted by deleting its related pole.
- When the edits are reconciled, an update-delete conflict will be detected.
Post changes
To post changes to the default version once you have reconciled and reviewed conflicts, click Post in the Versioning group on the Versioning tab.
During the post process, conflicts can be discovered. This can occur when edits are performed on the default version after your reconcile and before the post process. These edits can be from direct edits to the default version, or from edits that have been posted from other named versions. If this occurs, an error is returned and you must perform the reconcile operation again before posting.
Once changes are posted, they cannot be undone, since you are applying changes to the target version.
If there are conflicts that have not been explicitly marked as reviewed, a dialog box appears when you post, warning that unreviewed conflicts will be automatically resolved. Click Yes to automatically resolve conflicts with the options you chose on the Reconcile dialog box and post the changes to the target version.
After posting, you can continue to make edits in your version. To apply these changes to the target version, you must perform the reconciliation, conflict resolution, and posting processes again.
If posting marks the end of your workflow, you can optionally delete the version you have been editing.