Branching strategy

About Branching

All project repositories located in Mind Studios GitLab repoopen in new window should contains all main branches according to company internal Branching workflows document. Main branches should be named exactly the same way as described in Branching workflows. Any changes can not be pushed straight forward to any of main branches, you should create merge request for that. It's very important to be sure that main branches have been protected!

Main branches

Name	Description
master	Master branch contains the latest “release” code (code of the latest production version of the product).
maintenance	Maintenance branch contains the latest “release” code. Maintenance branch should be created in case, when bug found in latest release.
staging	Staging branch contains the code of “release candidate” (next release version).
development	Development branch contains “ready for testing” code of the product.

How to create and to protect main branches on GitLab you can read here.

Work branches naming

• Feature branch name should be: feature/ID_NAME. Where ID - Redmine feature id, NAME - name of the feature.

  Example: feature with the name “Sign in” and Redmine id "123" should be named as feature/123_signin.

• Task branch name should be: task/ID_NAME. Where ID - Redmine task id, NAME - name of the task.

  Example: task with the name “Data model” and Redmine id "321" should be named as task/321_data_model.

• Bug branch name should be: bug/ID_NAME. Where ID - Redmine bug id, NAME - name of bug.

  Example: bug with the name “Incorrect error message” and Redmine id "456" should be named as bug/456_incorrect_error_message.

Notes

• More information about branch to environment relation and bug fixing you can find in Branching workflows document.