Branching strategy **DRAFT**

Branching strategy coordinates work to allow for easier integration of changes and releases. It creates a development workflow. Branching strategy include feature branching and main/master-based development. It can allow developers to work on tasks simultaneously as part of a team.

For better automatic processing we will use prefixes for different branch types.

Three branch type name patterns are with protected access. They are:

• main/

• master/ (we should try and use "main" for new projects)

• release/x.x branches are created (branched from main/master) to get a stable version of software after all features are implemented, well tested und reintegrated to main/master. In this branches in normal flow only bugfixing is allowed

This means that, now that most people are not Owners or Maintainers in Gitlab, you are not allowed to push directly to these branches.

For detailed permissions of your role look here:https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions

Not with protected access but reserved branch type names are:

• feature/ Feature branches are branched from main/master and will be reintegrated to main/master after new feature is tested well. Substantial new features and breaking changes are generally released with Major versions only.

• issue/ Bugfixing branches are branched from main/master or from release/ branches and will be reintegrated to main/master or release/ after bugfix is tested well.

Gitlab provides several merge methods.

We will use “Merge commit with semi-linear history”. A merge commit is created for every merge, but the branch is only merged if a fast-forward merge is possible. This ensures that if the merge request build succeeded, the target branch build also succeeds after the merge. If fast-forward-merges is not possible, a rebase of feature/ or issue/ branch before the merge has to be performed.

Note: Never rebase main/ or release/ !

An example commit graph is here:

Who is able to push?

tbd.