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.
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.
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 detects conflicts between the named version that you are currently connected to and the default version. 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.
To make changes to how conflicts are handled during the reconcile operation, see Versioning options for editing.
To perform the reconcile process, you must be using web feature layers that have the Version Management capability enabled. You can access the Reconcile command on the Versioning tab by clicking the List By Data Source button 
in the Contents pane. To start the reconcile process, click the Reconcile button on the Versioning tab. The Reconcile dialog box appears.
When the Reconcile dialog box appears, provide the following information:
- Specify how you want conflicts to be defined. You have the following options:
Define conflicts at this level To detect these cases Row (by object)
A second user edits the same row or feature, or topologically related features, as you did. The conflict occurs even if you edited different attributes.
Column (by attribute)
A second user edits the same attribute of a feature or table. This is the default.
Options for defining a conflict
Note:
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.
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.
If conflicts exist, you can review them in the Conflicts view.
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.
Review conflicts using 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. Conflicts are organized using the data source, class, conflict category, and ObjectID. 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.
The Conflicts view also contains a Conflict Display for viewing the different representations for geometry edits. The content in the conflict display differs depending on whether the conflict class is present in the active map:
- When the conflict class is in the active map, the conflict display shows all map layers, uses the map symbology, and includes the basemap.
- When the conflict class is not in the active map, the conflict display only shows the layer in conflict, uses the default symbology, and does not include the basemap.
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.
Note:
All fields are displayed in the Conflicts view; however, fields with a conflict filter applied are not identified as in conflict and do not display a red indicator.
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.
To prevent conflicts from being identified when the same attribute is updated in the parent and child versions, 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. Conflicts will not be returned during the reconcile operation if only fields with conflict filters are edited. This is only applicable when you are defining conflicts by attribute.
Note:
All fields are displayed in the Conflicts view; however, fields with a conflict filter applied are not identified as in conflict and do not display a red indicator.
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:
- In a parent version, you add a destination feature and relate it to a feature in the origin class.
- In a child version, you delete the same origin feature that was used to relate the new destination feature.
- When the edits are reconciled, an update-update conflict is detected on the destination class while a delete-update conflict is detected on the origin class.
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 is detected on the origin and destination classes.
In this last example, if the second editor chose to replace all conflicts with the edit session representations, the pole and transformer deleted during your edit session will be re-created.
Post changes
To post edits to the default version, the current portal user must have access to edit this version. This means the default version must have the access property set to public, or the portal user must be the version administrator.
Learn more about version access
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.
Additional information about the post process:
- 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 reconcile, conflict resolution, and posting processes again.
If posting marks the end of your workflow, you can optionally delete the version you have been editing.