allow for hotfixes

this allow to do hotfixes that bypass the normal release flow, but still creates clear tags.

You can toy around with it on https://git.panter.ch/manul/lab/ci-test/

TBD:

• after a hotfix-tag has been created, the pipeline runs, but does not deploy automatically anywhere, because you probably do not want to override the current stage version. But maybe we automatically deploy to prod right away? That would avoid one manual step and by that time you had plenty of oportunities to review what you fixed.

README.md

@@ -48,6 +48,33 @@ You can create a release manually on the repository, which does a `semantic-rele
 
 After the repository got tagged, a deploy to prod or stage is done (depending on whether staging is enabled, see below).
 
+In the pipeline, click on "create-release" to create a release tag and trigger therefore a new release.
+
+### hotfixing older release
+
+You might come accross the situatio where you have a tagged version that is about to get released,
+but its still getting tested by the customer on staging.
+
+Now, a wild bug occures and you have to fix that on production!
+
+With the normal workflow you would need to fix that, merge it into master and trigger a normal release.
+But this will release everything that is on stage right now!
+
+To avoid this, you can do this hotfix flow, which follows [this recipe](https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/maintenance-releases.md):
+
+Let's assume your current "good" version on prod is `v2.4.3`
+It's important that this version is the latest `patch` version so (v2.4.4 does not exist). This is usually in praxis, as you want to release bugfixes as soon as possible usually.
+So we want to have a new patched version 2.4.4 that will be our new prod :
+
+- create a branch for the hotfix: `git checkout -b 2.4.x v2.4.3
+- do your fixes and commit with a `fix:` commit: `fix: very important bug to hotfix`
+- push this branch to gitlab
+- this will now trigger a special pipeline where you have your usuall lint/test/build and review deploy.
+- Additionaly this pipeline contains a "create-release"-step. Run this job to create the new hotfix release 2.4.4.
+- this will in turn run a pipeline that let's you deploy it to prod and stage. its not done automatically. Chose the right destination for your hotfix.
+- pull the branch again locally (if you want to have it in the changelog file) and merge it into master
+- this might lead to conflicts now if the hotfix no longer applies, but that's ok! Maybe it was already fixed in some stage feature.
+
 ### enable staging
 
 if you set `STAGING_ENABLED: "true"` in your `variables`, it will deploy to stage first when doing a release. You can then do the prod release manually.