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.

Table of contents

Branching

When creating a new feature it is recommended to create a feature branch (return to 2. 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:

Tips & tricks

(tick) Agree upon a naming convention for branches. Examples: release or application version for release branches or ticket/user story number for feature branches.

(tick) Do not hold on to (many) old branches; rather tag your trunk consequently to be able to create a branch at a certain revision when necessary.

(tick) Keep the amount of active branches small to prevent conflicts and to remain overview. 

Registering & managing changes

After implementing a new feature it is time to register what you have changed and why these changes were made. This information can be described in the commit 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.

Tips & tricks

(tick) Use tags to mark releases or milestones or any other important versions. This will make it easy to create a new branch, e.g. for creating a hotfix branch or to be able to view an old revision without the need to keep old branches.

(tick) It is possible to protect a branch type, for example, the release branch, in such a way that it is not possible to make direct changes to edit content in that branch other than merging changes to this 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:

Tips & tricks

(tick) 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!

Previous: 2. Version management strategy

  • No labels

Didn't find the answer you were looking for? Try the advanced search!