In the previous parts the (Blueriq) basics about version control and version management strategies have been discussed. This final part is about managing versions in Blueriq and can be seen as an overview of the available how-to articles and documentation on the subject. This includes creating branches, registering changes, merging changes and solving conflicts.
Note: the basics and features can be found in the documentation Version management [editor].
Branching
When creating a new feature it is recommended to create a feature branch (review Version management strategy to learn about different branching strategies), especially in case of high impact features or when implementation takes multiple release cycles or release date is uncertain.
The basics and features are described in the documentation. For a step-by-step guide on creating a (feature) branch, please refer to:
Registering & managing changes
After implementing a new feature it is time to register what you have changed and why these changes were done. This information can be described in the registration message. Often this is a combination of a ticket/user story number (reference to an issue tracking system) and a short description of the change.
A registration message cannot be altered once the changes have been committed.
The basics and features are described in the documentation. For a step-by-step guide on registering or undoing a change, please refer to:
At this point it is also possible to add tags to the registration. A tag can also be added (edited or removed) after registration when you view the history of registers through version management or from within the change's project.
Add tags to indicate milestones, releases or any other important versions. This will keep the branch and history organized and will help creating a branch at specific working revision or release version, e.g. to create a bug fix branch.
Merging & conflicts
After a (set of) change(s) is registered it might be necessary to update the stable trunk version of the application or synchronize the changes to other branches, this is called merging. Merging two branches can result in conflicts when the same element is subject to changes in both branches.
The basics, features and different types of conflicts are described in the documentation. For a step-by-step guide on merging two branches and how to solve occurring conflicts, please refer to:
Keep branches short-lived and the number of active branches limited to a minimum to prevent conflicts.Versions will be easier to manage and maintain and merging will be more fun without conflicts!
Overview
Content Tools