Versions Compared

Old Version 6

changes.mady.by.user Unknown User (e.marcelis)

Saved on

compared with

New Version Current

changes.mady.by.user Tijmen Daatselaar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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]

.

Panel
titleTable of contents
Table of Contents
maxLevel1

Branching

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

tip

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 registration 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.  

Note

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.

TipAdd

Tips & tricks

(tick) Use tags to

indicate

mark releases or 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

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.

to create a bug fix

(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:

tip

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!

 

 

Panel
Section
Column

Previous: 1. What is version control? 2. Version management strategy