Non-SaaS Product GIT Branching Strategy

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.