i

Description

Une branche qui se divise en deux, prise dans un manchon de glace sur fond de ciel bleu.

Source

Velatrix · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Branching Strategies

Understand why we branch, and what a branch that lives too long costs.

In brief

• Understand why we branch, and what a branch that lives too long costs.
• Know the reference strategies: trunk-based, GitFlow, GitHub Flow, GitLab Flow, release branches, branches by product version.
• Know how to apply this to the TFVC world (Main/Dev/Release, merges, baseless) and to release snapshots.
• Use feature toggles to decouple merging and delivery.
• Choose a strategy for a SQL/BI project, with /5 ratings by context.

On this page

1. Why branch
2. The cost of a branch
3. Trunk-based development
4. GitFlow
5. GitHub Flow
6. GitLab Flow
7. Release branches
8. Branches by product version
9. TFVC and standard branches
10. Feature toggles
11. Strategies for SQL and BI
12. Ratings by context
13. Conventions and protections
14. Pitfalls
15. See also

Level: 🟢→🔴

Why branch#

🟢 Novice level

A branch isolates a development line: you work on an evolution without disturbing stable code. We branch for three reasons: isolate work in progress (feature, fix), stabilize (prepare a version while development continues), maintain (fix a version already delivered). A project without branches works on a single trunk; an over-branched project spends its time merging.

The cost of a branch#

🟢 Novice level

Branching is free; merging is not. The cost of a merge grows with how long branches diverge and the number of files touched on both sides. Two effects:

1. Textual conflicts: same lines modified.
2. Semantic conflicts: code merges without conflict but no longer works (column renamed on the SQL side, new use of the old column on the report side). These are the most expensive, because no tool flags them.

Trunk-based development#

🟡 Practical level

Principle: everyone integrates into a single trunk (main), through very short branches (hours to 1-2 days) or directly. Unfinished features are hidden by feature toggles. A release branch is cut only to stabilize/maintain.

Prerequisites: fast and reliable CI, automated tests, lightweight review (or pair programming), discipline around small commits. In delivery performance literature (DORA research, Accelerate), this practice is the one most associated with better delivery metrics.

Strengths: minimal merges, true continuous integration, visibility. Limits: requires test maturity; difficult with deliveries in separate packages with long maintenance without release branches; uncomfortable when trunk cannot break (no reliable CI).

GitFlow#

🟡 Practical level

Model published by Vincent Driessen in 2010: permanent branches master (production, labeled main in the diagram) and develop (integration), temporary branches feature/*, release/*, hotfix/*.

main     ──●────────────────●─────────●── (tags v1.0, v1.1)
            \              /         /
release      \      ●──●──●         /
              \    /               /
develop  ──●───●──●──●──●───●──●──●────
              \   /  \       /
feature        ●─●    ●──●──●

Strengths: clear framework for planned versions at a slow pace, parallel maintenance of multiple versions. Limits: heavy (two permanent branches, multiple merges), delays integration, discouraged by its own author for continuously delivered applications (note added by the author to his article in 2020). Still relevant for versioned products delivered as packages.

GitHub Flow#

🟡 Practical level

Very simple: main is always deployable; you create a short branch, open a pull request, review, test, merge, deploy. No develop, no release branches. Suited to an application in continuous deployment and a small to mid-sized team. Insufficient when you must maintain multiple versions installed at customers.

GitLab Flow#

🟡 Practical level

Variant: environment branches (staging, production) or release branches (release/9.1) downstream from main. Changes go from main downstream only (“upstream first”: fix first on main, then backport). A compromise between GitHub Flow simplicity and the need for maintained versions. Often the best starting point for a product team.

Release branches#

🟡 Practical level

A release branch (release/9.1) is cut when the version is “almost ready.” On it: only fixes (no new features). Meanwhile, main continues toward the next version. Golden rule: fix on the oldest affected branch, merge forward (or “upstream first” then backport via cherry-pick with -x if models diverge).

Cycle: main → release/9.1 (cut) → hardening, fixes → tag v9.1.0 → later fixes 9.1.1, 9.1.2 on the same branch → end of support.

Branches by product version#

🟡 Practical level

For a product delivered to customers who stay on different versions (typically 8.0, 8.1, 9.0, 9.1…), each maintained version has its own branch (or folder), with a long lifespan. Two variants:

The “snapshots in folders” model is common in TFVC (branches are folders there). Its flaw: no merge relationship between folders if they were copied instead of branched; each multi-version fix then becomes a manual hand cherry-pick operation (or baseless merge), with no trace of what has already been propagated. Remedy: keep the branch relationship (declared TFVC branches or Git branches), and maintain a fix propagation matrix (which defect fixed in which versions).

Minimum propagation matrix (to keep in the ticket or release page):

TFVC and standard branches#

🟡 Practical level

The historical Microsoft guide (Branching and Merging Guide, Visual Studio ALM Rangers) describes models: Main Only (single trunk); development isolation (Main + Dev); feature isolation (Main + Feature); release isolation (Main + Release); maintenance and release isolation (Servicing + Release). The “code promotion” model is no longer recommended there. In short:

$/Projet
  Main                      (stable integration)
  Dev                       (current development)
    Feature-ABC             (short branch)
  Releases
    R9.0   R9.1             (maintenance)

Rules of the standard model:

• Upstream/downstream flow: Dev → Main (RI, reverse integration), Main → Dev (FI, forward integration). A lateral merge (R9.0 → R9.1) is not allowed without passing through Main, except baseless.
• Integrate often into Dev to reduce drift; reintegrate in tested batches into Main.
• Release branches created from Main at freeze time; fixes on the release then merged into Main (reverse integration) to avoid regressions.
• Baseless merges (tf merge /baseless): outside branch relationship; reserved for special cases (see 03). Each baseless merge is a roll of the dice on conflicts.

/5 ratings of the TFVC “Main + Releases” structure for a product maintained across 4 versions (team of 5-15):

Feature toggles#

🔴 Expert level

A feature toggle (feature flag) allows you to merge unfinished code without activating it. It decouples deployment and go-live. Types: release toggle (short term, hides a feature in progress), ops toggle (disable in an emergency), experiment toggle (A/B), permission toggle (by client).

Data/BI application:

• Parameter _Parameter in the database that activates a new calculation or a new join; the same procedure contains both paths, selected by parameter (tested on both sides); remove the old path and the parameter once validated.
• DAX measures in parallel (old/new) with switching via field parameter or calculation group, without deleting the old one (client reports remain linked to the existing one).
• Hidden report pages for a feature in acceptance testing (reminder: “hidden” is not “inaccessible”).

Cost: toggle debt (dead code, test combinatorics). Each toggle has a removal date and an owner.

Strategies for SQL and BI#

🔴 Expert level

Specifics that change the answer:

1. Deployment is not code: a database schema carries state (data, existing tables); two branches that modify the same table produce conflicting migrations even if the files do not touch. See 06.
2. Reports are coupled to the model: a column renamed in SQL breaks the semantic layer and reports. Branch in vertical slices (SQL + model + report together) in a monorepo, or coordinate PRs.
3. BI files merge poorly (.pbix): PBIP/TMDL format to enable merging (see 06).
4. Multiple versions installed at client sites: maintenance branches or snapshots; installation kits by version.
5. Business acceptance testing: validation on numbers requires environments; the “release” branch must have its test environment.
6. Partial continuous integration: you cannot always fully rebuild the whole datamart on every commit; plan a partial load test (sample) on each PR and full rebuild at release (CI/CD for Data: Databases, Datamarts, Pipelines, and Reports).

General recommendation for a 5 to 30-person team on a datamart + BI with maintained versions: “lightweight” trunk-based (short branches, PRs) + release branches per maintained version + fix first on the oldest affected branch and merge forward + signed tags + propagation matrix.

Ratings by context#

🔴 Expert level

Ratings /5; criterion: fit of the strategy to each context (see RATING). Reading: a low rating is not a flaw, it is a poor match.

Conventions and protections#

🟡 Practical level

• Naming: feature/<ticket>-<subject>, fix/<ticket>-<subject>, release/<version>, hotfix/<version>-<subject>.
• Protections: main and release/* forbid force-push and deletion; mandatory PR with at least one reviewer; validation build; link to a work item; comment resolution.
• Merge: squash for short feature branch, merge commit to preserve release topology, rebase for linear history. Choose one convention per branch type and document it.
• Versioning: semantic versioning MAJOR.MINOR.PATCH; annotated (signed) tag per delivery; release branch deleted only at end of support.
• Lifespan: automatic deletion of merged feature branches.

Pitfalls#

🔴 Expert level

• ⚠️ Pitfall — Eternal “Dev” branch: the integration branch drifts from trunk; each reintegration becomes a project. Remedy: merge often, or remove Dev.
• ⚠️ Pitfall — Cherry-pick without trace: the same fix exists under four IDs; later merges flag it again as a conflict. Remedy: -x, propagation matrix, upstream-first fix.
• ⚠️ Pitfall — “Open” release branch: features get slipped into it. Remedy: “fixes only” policy, PR enforcement.
• ⚠️ Pitfall — Unseen semantic merge: tests green, numbers wrong. Remedy: acceptance testing on three business totals before tagging.
• ⚠️ Pitfall — Wrong tool for the problem: GitFlow for a 4-person team in continuous deployment; GitHub Flow for 4 maintained versions.
• ⚠️ Pitfall — Releases/ folder copied manually: see above, no merge relationship.

See also#

• Git In Depth · TFVC In Depth · Git vs TFVC: Compare, Migrate, and Coexist · VCS and SQL / BI
• Matrix: version control and branching
• CI/CD · CI/CD for Data: Databases, Datamarts, Pipelines, and Reports
• Glossary

✻ Written by Claude Sonnet 5.5