Workflow ​

Feature/Story development ​

1. Create a branch based on development with name:

   • With Shortcut story: type/story-id/story-name (you can use the Shortcut git helpers for this)
   • Without Shortcut story: type/short-description

   The type should be one of feature, bug or chore (same as story type). For temporary test branches use the type test. Use the story-name or the short-description for some keywords (not too long) which will help to quickly identify the content of the branch.

2. Make the changes to your feature branch

   TIP

   You don't have to follow the Commit messages convention. However, in case the merge request does only contain one commit, the commit message must follow the Commit messages convention.

3. Merge any other changes from development to your feature branch

   Your feature branch must be 0 commits behind development.

   TIP

   Remember merging development into your branch during development to avoid a lot of merge conflicts later on.

4. Check the status of the GitLab pipeline of your branch

   The pipeline must finish successfully before the branch can be merged.

5. Create a merge request for your feature branch into development

   • The title must follow the Commit messages convention
   • Select Delete source branch when merge request is accepted.
   • Select Squash commits when merge request is accepted.

6. The merge request will be merged by a maintainer if accepted

   In case the merge fails:

   • Check that you selected Squash commits and the merge commit message follows the Commit messages convention.
   • If the merge request contains only one commit the commit message must follow the Commit messages convention.

Deployment of releases and pre-releases ​

In case you don't use a staging branch, then start with step 4 and use development instead of staging.

1. Create a merge request to merge development into staging

   WARNING

   Do not select Squash commits when merge request is accepted. Otherwise, the staging branch will have a different commit history than development and must be merged back.

2. Accept the merge request if changes are correct and pipeline was successful

3. Test/Verify the pre-release version

   Step 1-3 can be repeated at any time.

4. Create a merge request to merge staging into release

   WARNING

   Again, do not select Squash commits when merge request is accepted..

5. Accept the merge request if changes are correct and pipeline was successful

6. Verify that the release pipeline was successful

Hotfixes ​

1. Create a branch based on release with name hotfix/<short-description> or hotfix/<story-id>/<story-name> with story reference

2. Make the changes in the hotfix branch

3. Create a merge request to merge the hotfix branch into the release branch

   • The title must follow the Commit messages convention
   • Select Delete source branch when merge request is accepted.
   • Select Squash commits when merge request is accepted.

4. Accept the merge request if changes are correct and pipeline was successful

   WARNING

   Keep in mind that your changes will be directly released and should not cause more trouble than before

5. Verify that the release pipeline was successful

6. Merge the release branch into the staging branch and then staging to development

   Normally this cannot be done with a merge request, because the commit history is different. Merge the branches locally.