Git Strategy Pitfalls

Git and CI/CD practices are extremely effective for many software products. They work particularly well when a product can be deployed frequently and when the main branch represents the current releasable version.

This page describes a common mismatch between tooling and product lifecycle.

A single-branch CI/CD flow becomes problematic when an organization must support multiple released versions of the same product at the same time.

The Simple Case

In the simplest scenario, a team develops version 1 of a product, merges it into the main branch, and produces a build artifact. That artifact is then promoted through environments such as Development, QA, UAT, and Production.

This approach is popular because it is easy to understand: the main branch is the source of truth, and pipelines simply move the same artifact forward.

Where the Pain Begins

The strategy becomes fragile as soon as these two conditions are true at the same time:

• Multiple product versions must be supported in parallel.
• Production issues must be fixed while development continues for future versions.

In this situation, the main branch is usually ahead of the version currently running in production.

A hotfix cannot safely be created from the main branch, because main already contains changes that belong to newer versions.

The Hotfix Cascade

To fix a production issue, the team typically has to:

• Locate the exact commit that corresponds to the production release.
• Create a hotfix branch from that commit.
• Build and deploy a patched version for production.

The work rarely ends there. The same fix usually must be applied again to newer versions that are already in QA, UAT, or active development.

Each supported version introduces its own branch, its own merge path, and its own release coordination. What started as a simple flow becomes a growing web of exceptions.

What This Means

This does not mean Git or CI/CD is flawed. It means the chosen branching strategy does not match the product’s release model.

If an organization produces software as distinct releases such as “Version N”, “Version N+1”, and supports multiple versions in parallel, then a single-branch flow needs additional structure:

• Long-lived release branches, one per supported version.
• A clear policy for propagating fixes across versions.
• Pipelines that explicitly target a specific release line.

Without this structure, CI/CD becomes a source of friction precisely when stability and speed are most critical.

A Note on Frequent Deployment

Frequent deployment works best when users expect continuous change. In business domains where releases represent contractual or operational milestones, too-frequent updates can be perceived as instability rather than progress.

The solution is rarely to abandon CI/CD. Instead, it is to align automation with release cadence and with the realities of long-lived product versions.

Table of Content Software Development Pitfalls Previous: Business Logic Development Pitfalls Next: Unit Testing Pitfalls in Business Domains