Git Branching Strategy

Overview This document will provide information about the software development processes, both for local development as well as the branching, tagging and pipeline running for our CI / CD workflow. This will be a living document to be updated as processes evolve to suit our needs. The goal is to keep things as simple as possible for developers while maintaining security in and a high standard of software delivered. GitHub Branching Strategy Classic Gitflow Gitflow is an alternative Git branching model that involves the use of feature branches and multiple primary branches. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete. These long-lived feature branches require more collaboration to merge and have a higher risk of deviating from the trunk branch. They can also introduce conflicting updates. This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases. Also developers get to leverage all the benefits of the Feature Branch Workflow: pull requests, isolated experiments, and more efficient collaboration. In addition, you may want to install a git-flow cli tool or create commands’ aliases. Branching model Our workflow uses two branches and tags to record the history of the project. The main branch stores the release history to the test environment, and the develop branch serves as an integration branch for features. Tags of the project store official releases history with proper versioning. Also, the presentation branch is used for the presentation environment and it is synced with the main branch. Feature branches Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of main, feature branches use develop as their parent branch. When the feature’s code and tests are complete, it gets merged back into develop. Developer starts working on code improvements, writing documentation, etc. Feature branches are generally created off to the latest develop branch and should never interact directly with main. Creating a feature branch with git (at this moment you may want to start creating aliases

Apr 26, 2025 - 15:43

Overview

This document will provide information about the software development processes, both for local development as well as the branching, tagging and pipeline running for our CI / CD workflow. This will be a living document to be updated as processes evolve to suit our needs. The goal is to keep things as simple as possible for developers while maintaining security in and a high standard of software delivered.

GitHub Branching Strategy

Classic Gitflow
Gitflow is an alternative Git branching model that involves the use of feature branches and multiple primary branches. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete. These long-lived feature branches require more collaboration to merge and have a higher risk of deviating from the trunk branch. They can also introduce conflicting updates.

This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases. Also developers get to leverage all the benefits of the Feature Branch Workflow: pull requests, isolated experiments, and more efficient collaboration.

In addition, you may want to install a git-flow cli tool or create commands’ aliases.

Branching model
Our workflow uses two branches and tags to record the history of the project. The main branch stores the release history to the test environment, and the develop branch serves as an integration branch for features. Tags of the project store official releases history with proper versioning. Also, the presentation branch is used for the presentation environment and it is synced with the main branch.

Feature branches
Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of main, feature branches use develop as their parent branch. When the feature’s code and tests are complete, it gets merged back into develop. Developer starts working on code improvements, writing documentation, etc.

Feature branches are generally created off to the latest develop branch and should never interact directly with main.

Creating a feature branch with git (at this moment you may want to start creating aliases