TSP Logo TSP Wiki
Docs
TSP Wiki

    Git Branch Workflow

    This document goes through a Git branch workflow that can generally be applied to most projects.

    Each project may have come up with their own modifications to adapt better to their requirements, but the main ideas from this document should still be applicable.

    Branches

    In general, there should be 3 main types of long-lived branches:

    • 1 for Dev/Develop
    • 1 for UAT/QA/Staging
    • 1 for Production/PROD

    Short-lived branches will include:

    • Feature branches
    • Bugfix branches
    • Hotfix branches

    Typically changes will be merged in the following flow:

    • Feature branch → Dev → UAT → Production

    Most changes will be made to short-lived feature or bugfix branches that are branched from the dev branch

    The image below gives a visual representation of the flow

    Git Workflow

    Dev Branch

    The dev branch is a long-lived branch that contains all the ongoing development changes. It serves as a staging area for integrating new features, bug fixes and other code changes. These changes will be deployed to the dev environment, where they will be tested.

    Each deployment from the dev branch to the dev environment should be tagged .

    By default, the dev branch should be protected, meaning no changes should be committed and pushed directly into the dev branch. Changes should be made to feature or bugfix branches that are created from the dev branch. When ready, those changes should be merged into dev via a merge request .

    Feature and Bugfix Branches

    Feature and bugfix branches are short-lived branches based on dev branch. These short-lived branches allow developers to work on their changes without affecting other team members. Once their work is complete, these branches should be merged into dev via a merge request .

    Naming Convention

    Naming conventions for feature and bugfix branches are as follows:

    • <name or initials>/<branch type>/<youtrack ticket ID>_<short description>

    Examples:

    • Alice is working on a new feature for multi-select filters under ticket YT-1045. Branch name could be alice/feature/YT-1045_multi-select-filters
    • Bob is working on a bugfix for ticket YT-1166, related to session timeout. Branch name could be bob/bugfix/YT-1166_session-timeout

    Hotfix Branches

    Hotfix branches are short-lived branches based on production branch. These branches are meant for severe bug fixes that urgently need to be deployed into production.

    Once a hotfix is ready, the branch should be merged into both dev and production using merge requests .

    Naming Convention

    Naming convention for hotfix branches are as follows: hotfix/<youtrack ticket ID>_<short description>

    UAT Branch

    The UAT branch is a long-lived branch that contains all the changes deployed to the UAT environment.

    By default, the UAT branch should be protected such that no changes can be committed and pushed directly into the UAT branch. In order to merge changes into the UAT branch, we create UAT staging branches, which will then be merged into the UAT branch via merge requests.

    After merging, the UAT branch should be tagged .

    UAT Staging Branches

    UAT staging branches are for merging changes into the UAT branch. They are branched from UAT branch.

    Naming convention should be uat/<version> , where version is the version of the application to be deployed to UAT (e.g. uat/v1.0.1)

    Changes to be deployed will be merged from dev into the staging branch, before being merged into UAT branch via a merge request .

    Production Branch

    The production branch is a long-lived branch that contains all the changes deployed to the production environment.

    By default, the production branch should be protected such that no changes can be committed and pushed directly into the production branch. In order to merge changes into the production branch, we create production staging branches, which will then be merged into the production branch via merge requests .

    After merging, the production branch should be tagged .

    Production Staging Branches

    Production staging branches are for merging changes into the production branch. They are branched from production branch.

    Naming convention should be prod/<version>, where version is the version of the application to be deployed to production (e.g. prod/v1.0.1)

    Changes to be deployed will be merged from UAT into the staging branch, before being merged into production branch via a merge request .

    Edit this page on Gitlab