Skip to main content

Git Branching Strategy

This page defines the Git workflow for the DeltaFM Facilities Maintenance application.

Goals​

  • Keep main production-ready.
  • Make active work visible and isolated.
  • Keep releases predictable.
  • Reduce merge conflicts and unclear ownership.

Branch types​

main​

  • Always reflects production-ready code.
  • Protected from direct pushes.
  • Updated only through reviewed pull requests.

dev​

  • Integration branch for the next release.
  • Feature branches are created from dev.
  • Completed work is merged back into dev.
  • Automatic deployment to test environment (possibly rename environment to dev)

feature/{Jira ticket}-*​

Use feature branches for normal development work.

Examples:

feature/DFM-8-add-work-order-export
feature/DFM-12-improve-asset-search

Rules:

  • Branch from dev
  • Keep scope focused on one change
  • Open a pull request back into dev

hotfix/* (Not needed for the moment as we are pre release)​

Use hotfix branches for urgent production issues.

Examples:

hotfix/fix-login-timeout
hotfix/repair-null-asset-crash

Rules:

  • Branch from main
  • Merge back into main
  • Also merge into dev so the fix is not lost in the next release

release/*​

Use release branches when preparing a production deployment.

Examples:

release/1.4.0
release/2026.04

Rules:

  • Branch from dev
  • Allow only stabilisation work such as versioning, testing fixes, and release notes
  • Merge into main when approved for production
  • Merge back into dev after release

Standard workflow​

  1. Create a branch from dev.
  2. Commit work in small, readable units, and include the Jira ticket in every commit message.
  3. Push the branch and open a pull request into dev.
  4. Complete review and checks.
  5. Merge after approval.

Commit message requirements​

  • Every commit must include a Jira ticket reference.
  • Use the same Jira ticket that appears in the branch name when applicable.

Example:

DFM-12 improve asset search performance

Hotfix workflow​

  1. Create a hotfix/* branch from main.
  2. Implement and validate the fix.
  3. Open a pull request into main.
  4. After release, merge the same fix into dev.

Pull request expectations​

  • Use a clear title that describes the outcome.
  • Link the relevant work item or ticket.
  • Include testing notes.
  • Require at least one reviewer.
  • Do not merge if checks are failing.

Naming conventions​

Use lowercase kebab-case branch names:

feature/add-preventive-maintenance-report
hotfix/fix-tenant-filter
release/1.5.0

Protection rules​

Recommended repository rules:

  • Protect main
  • Protect dev
  • Require pull requests before merging
  • Require status checks to pass
  • Block force pushes
  • Block branch deletion for protected branches