Page History
...
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 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.
...
| Tip |
|---|
Agree upon a naming convention for branches. Examples: release or application version for release branches or ticket/user story number for feature branches. |
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 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.
...
| Tip |
|---|
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.
...
Overview
Content Tools