Forum Discussion

GeorgeAbraham's avatar
GeorgeAbraham
Copper Contributor
Nov 18, 2023

Non-SaaS Product GIT Branching Strategy

Dear Team,

 

What’s your recommended approach?

 

A non-SaaS product

Two repos - Backend and Frontend

Current Approach -

Dev, QA and Prod Branches

Sprint branch (can’t go with feature branch as multiple unlimited APIs and multiple user stories will impact the same set of APIs) created out of Dev and merged into Dev at end of sprint

Post each Sprint Dev branch tagged and PR into QA branch

Customers are given Docker images generated out of specific tags from QA branch

 

Now comes the fun part-

 

Say customer 1 on Tag v4.3.0, customer 2 on Tag v4.4.0 and product last release is Tag v4.5.0. Current active sprint once complete would be v4.6.0

 

Developers currently working on active sprint branch for v4.6.0

Bug 1 reported by customer 1 in v4.3.0

Bug 2 reported by customer 2 in v4.4.0

 

I can extract the specific tag code, make the changes, then manually make the changes in other tags and release to those customers if common bug, or else manually make the changes in active branch also so that next release it’s not missed

 

What if Bug 1 is a Feature for customer 2 who doesn’t need it? So where will I store these changes? Which branch?

 

I want to avoid having customer

specific branches as it becomes a big overhead.

 

Suggestions welcome!

azure devops
versioning

1 Reply

  • Kidd_Ip's avatar
    Kidd_Ip
    MVP
    Jul 16, 2025

    How about Tag-Based Hotfix + Modular Feature Flags:

     

    1. Introduce a hotfix Branch per Release Tag
    •    When a bug is reported on a tag (e.g. v4.3.0), create a hotfix/v4.3.x branch from that tag.
    •    Apply the fix there, tag it as v4.3.1, and deliver the Docker image to customer 1.
    •    If the fix is relevant to other versions, cherry-pick into hotfix/v4.4.x or dev as needed.

    2. Use Feature Flags for Optional Behavior
    •    If Bug 1 is a feature for customer 2, wrap the change in a feature flag.
    •    This allows you to include the code in shared branches (like dev or QA) but toggle it per customer config.
    •    Avoids branching explosion while supporting divergent needs.

    3. Tag Every Customer Delivery
    •    Continue tagging QA merges (e.g. v4.3.1-cust1, v4.4.2-cust2) to track what each customer received.
    •    Use annotated tags with metadata or maintain a delivery manifest.

    4. Backport with Cherry-Pick, Not Manual Rewrite
    •    Instead of manually replicating fixes across versions, use git cherry-pick to apply commits from one hotfix branch to others.
    •    Helps maintain consistency and traceability.

    5. Avoid Customer-Specific Branches, Use Config-Driven Builds
    •    Keep a single QA branch and use build-time config or Docker ENV to customize behavior per customer.
    •    This keeps your Git history clean and avoids long-lived divergent branches.

     

Resources