Conflicts Resolution
Previous Steps
Before reading the Conflicts Resolution documentation, you need to choose a versioning scheme for your project and read the Integration documentation.
When integrating two branches, Git compares their differences with respect to the common commit ancestor. A conflict generates when it detects that the same lines of the same file have been modified in both branches, and it cannot automatically decide which one to keep.
The more branches and developers work in parallel, the more likely it is that conflicts will arise, so the tool will need of your intervention in order to resolve ambiguities in the changes.
Important
When resolving conflicts in Studio, instead of choosing one change over the other in one entity, the whole source or target entity is replaced. For example, if we modify the same screen in both branches, when resolving the conflict by selecting the source, the target screen is discarded and replaced by the source screen in its entirety.
How to detect the origin of a conflict
Studio displays the files involved in a conflict and details the action taken on each branch: whether a file was added (+), deleted (-) or edited (pencil icon). However, when a file was edited in both branches, Studio does not allow you to view the specific changes made in each branch.
In order to review in detail what changed in each branch and make a better decision on how to resolve the conflict, it is necessary to use tools external to Studio. In this case, it is suggested to use GitLab and IntelliJ (although any other IDE can be used).
Follow these steps:
Login to GitLab (you can use the Studio shortcut Go to GitLab).
Clone the repository locally.
Open the project in IntelliJ.
Replicate the Merge Request you are trying to perform in Studio.
Review the conflicting files and analyze the differences line by line.
Then, with this analysis made, resolve the conflict in Studio. Read each conflict resolution standards guide to learn how to proceed depending on your integration scenario.
General Standards for Conflict Resolution
These conflict resolution standards are designed for both feature and trunk-based versioning schemes and allow you to know how to proceed depending on your scenario.
In this section, you will find:
how to resolve conflicts in pulls between release branches;
how to keep both changes in a merge; and
how to merge with conflicts external to Studio.
Conflicts Resolution in Feature-based Versioning
Since there can be multiple branches and integrations in the feature-based model, it is more likely to generate conflicts when trying to merge. Solutions will vary depending on the needs and the working methodologies.
In the feature-based model, conflicts can be resolved:
in the release branch;
in the feature branch; and
in a pre-release integration branch.