PC SOFT

WINDEVWEBDEV AND WINDEV MOBILE
ONLINE HELP

Home | Sign in | English UK
  • Principle
  • Merge window
  • Initial display
  • Conflict of code changes
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadApple WatchUniversal Windows 10 AppWindows Mobile
Others
Stored procedures
Principle
The management of branches is used to manage several versions of the same application in parallel.
The most common case is as follows:
  • You have deployed a version of your application and you are working on the next version of this application.
  • Meanwhile, you would like to apply the bug fixes performed in the current version to the deployed version, and therefore create and deploy intermediate versions.
Branches are usually represented on a timeline.
Example:
In this example, there is a main branch (named "My Version") from which a "Version 1" branch has been created. The origin is the state of the project at the time the branch was created. This origin is noted in the branch: it will later allow an automatic merge.
In our example, changes have been made both in the main branch and in the "Version 1" branch. We want to reintegrate all the modifications of the main branch into "Version 1" by merging branches.
To perform this merge, three elements will be compared:
  • The state of the project at the time the branch was created (origin).
  • The current state of the main branch ("My Version").
  • The current state of the "Version 1" branch.
By comparing the files in these three states, it is possible to calculate a merge of the two branches.
This merge is then reintegrated into the "Version 1" branch. Since the branches are now merged, the time of merging becomes the new origin that will be used for the next merge if necessary.
Merge window

Initial display

The merge window only appears when a conflict appears. This window shows the three moments of comparison.
For each element:
  • the "Modification" column shows the action performed on the element,
  • the "Origin" column shows if the element was present or not at the origin (creation of the branch),
  • the "My version" column (in green) corresponds to the state of the element in the initial version.
  • the purple column corresponds to the state of the element in the branch.
  • the "Result" column corresponds to the result of the merge.
By default, this window proposes a merging of the elements. For example, if the element does not exist in the origin or in my version, but if it exists in the branch, it will be proposed in the result of the merge.
You can choose the elements to be taken into account in the merge for each element: just click on the table cells that correspond to the version to be taken into account for the merge.
The colored dots in the "Result" column represent the version(s) from which the changes will be retrieved:
  • : purple dot: the element (or code) is retrieved from the branch.
  • : green dot: the element (or code) is retrieved from "My version".
  • : empty dot: the element (or code) is retrieved from the original version (branch creation point).
  • / / / : the element (or code) is a merge between the origin, the branch or the current version.

Conflict of code changes

When a code conflict is detected, the "Edit the code" link appears in the merge window. This link displays the merge window for differences in the code.
This window is divided into three parts:
  • "My version" (column in green): corresponds to the code in the initial version.
  • the "Result" column: corresponds to the merged code that will be used.
  • the last column (in purple) corresponds to the code used in the branch.
In this window, just use the arrow buttons to merge the code into the result area.
Note: the option "View original version" allows you to add a fourth column corresponding to the code of the original version.
Minimum version required
  • Version 23
This page is also available for…
Comments
Click [Add] to post a comment