Skip to content

Change workflow by changing from 'master' and default 'dev' branches to a single 'main' branch

For now, we use a procedure of release (see CONTRIBUTING.md) by working directly on the dev branch.

When the commits for the release are done locally on the developer repository, they are pushed to Gitlab on the dev branch.

If the integration tests failed, we are stuck because the dev branch is protected. The only solution is to remove the protection to allow a force push on the dev branch.

Do you see it coming ? A force push on a critical branch containing all the commits since the last release ?

What happens if the local repository of the developer is not up to date with the Gitlab dev branch ?

The problem has just happened, and I propose a new workflow to secure the process:

  • We remove the dev branch after the next release, when it is on the same commit as the master branch as it is useless in the new workflow.
  • For every release, we create a release_x.y.z branch to work on the release commits, and use it to create a MR.
  • If integration tests fail, we can just force push on the release_x.y.z branch, no risk here.
  • When the MR is approved, we merge the release branch in master.

The advantage of this workflow is also to have a default master branch with an up to date stable code, coming from the approved and tested MR.

We always have the release tags for the release references.

Edited by Moul
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information