Branching workflows

Main branches

• 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.

!!! Danger "Main branches should be protected!"

Work branches

• Feature branch name should be: feature/FeatureId_FeatureName. Where FeatureId - Redmine feature id, FeatureName - name of the feature. For example: for feature with name “Sign in” feature branch name should be feature/123_signin.
• Task branch name should be: task/TaskId_TaskName. Where TaskId - Redmine task id, TaskName - name of task. For example: for task with name “Data model” task branch name should be task/321_data_model.
• Bug branch name should be: bug/BugId_BugName. Where BugId - Redmine bug id, BugName - name of bug. For example: for bug with name “Incorrect error message” bug branch name should be bug/231_incorrect_error_message.

!!! tip "PS. Branches should have clear names." - Example with incorrect name: task/bugfix. - Bug branch name should start from “bug”, not from “task” or something else. - Bug branch name should have clear name, not “bugfix”. Fix for which bug that branch contains?

Relation: branch to environment

Branching strategy

Hierarchy

1. Master branch hasn’t “parent” branch. Master - it’s a main branch.
2. Maintenance branch should be branched from Master branch.
3. Staging branch should be branched from Master branch.
4. Development branch should be branched from Staging branch.
5. Feature branch (feature/FeatureId_FeatureName) should be branched from Development branch.
6. Task branch (task/TaskId_TaskName_1, task/TaskId_TaskName_2) should be branched from Feature branch (feature/FeatureId_FeatureName).
7. Bug branch (bug/BugId_BugName_1, bug/BugId_BugName_2) should be branched from where it was found (for example Development branch).
8. Bug branch (bug/BugId_BugName_1, bug/BugId_BugName_3) should be branched from where it was found (for example Maintenance branch).

Workflow (Task)

1. Task branch should be branched from Feature branch.
2. After local changes all actual changes should be commited.
3. Task branch should be merged with Feature branch (many developers can work with this task).
4. Task branch should be pulled (in cases, when that branch already exist in origin).
5. Task branch should be pushed to remote repository.
6. When work with Task branch was finished, branch can be merged to Feature branch (Developer should create merge request at GitLab web interface).

Workflow (Main branches)

!!! tip "Precondition:" - Child branch = Development branch for example. - Parent branch = Staging branch for example.

1. After local changes all actual changes should be commited.
2. Child branch should be merged with Parent branch.
3. Child branch should be pulled (in cases, when that branch already exist in origin).
4. Child branch should be pushed to remote repository.
5. When work with Feature branch was finished, branch can be merged to Development branch (Developer should create merge request at GitLab web interface).

Branching strategy (Bug fixing)

Case 1 (Bug was found in Master branch)

1. Maintenance branch should be branched from Master branch.
2. Bug branch (bug/BugId_BugName) should be branched from Maintenance branch.
3. After local changes all actual changes in Bug (bug/BugId_BugName) branch should be commited.
4. Bug branch should be merged with Maintenance branch.
5. Bug branch should be pulled (in cases, when that branch already exist in origin).
6. Bug branch should be pushed to remote repository.
7. Maintenance branch should be merged with Master branch.
8. Maintenance branch should be pulled.
9. Maintenance branch should be pushed to remote repository.
10. When work with Maintenance branch was finished, branch can be merged to Master branch (Developer should create merge request at GitLab web interface).
11. After merging to Master branch changings should be merged to Staging and then to Development branch.

Case 2 (Bug was found in Staging branch)

1. Bug branch (bug/BugId_BugName) should be branched from Staging branch.
2. After local changes all actual changes in Bug branch should be commited.
3. Bug branch should be merged with Staging branch.
4. Bug branch should be pulled (in cases, when that branch already exist in origin).
5. Bug branch should be pushed to remote repository.
6. When work with Bug branch was finished, branch can be merged to Staging branch (Developer should create merge request at GitLab web interface).
7. After merging to Staging branch changings should be merged to Development branch.

Case 3 (Bug was found in Development branch)

1. Bug branch (bug/BugId_BugName) should be branched from Development branch.
2. After local changes all actual changes in Bug branch should be commited.
3. Bug branch should be merged with Development branch.
4. Bug branch should be pulled (in cases, when that branch already exist in origin)
5. Bug branch should be pushed to remote repository.
6. When work with Bug branch was finished, branch can be merged to Development branch (Developer should create merge request at GitLab web interface).