- Description
- Aiguillage ferroviaire manœuvré à la main, où la voie se sépare en deux, avec sa lanterne de signalisation.
- Source
- PIVISO · original page
- Licence
- CC0 Public domain
Version Control and Branches
This theme measures traceability and the flow of change: can you track who changed what, why, and in which version; how long a branch lives before being integrated …
In brief
This theme measures traceability and the flow of change: can you track who changed what, why, and in which version; how long a branch lives before being integrated; how much a merge costs. It applies to any source control system — Git as well as TFVC; the promises do not depend on the tool.
Level: 🟢→🔴 · Theme code: GIT (DL matrix)
Why this theme#
The cost of a merge grows faster than linearly with the duration of branch divergence: the longer two code lines evolve separately, the more conflicts appear, subtle ones (semantic conflicts the tool cannot detect), and risky ones. Long-lived branches delay feedback and bundle changes into large batches, which means larger risks. This theme is the pivot between testing and continuous integration.
A note on installation packages delivered by version (for products delivered “on-premises”): per-version maintenance branches are legitimate, but every fix must be able to be ported to other versions without manual copying. The detailed branching strategy is in Branching Strategies.
What the theme measures#
- Axis: from “versions are folder copies” to “change flows in small batches to the main line, with full traceability”.
- Key indicators: median age of a branch or active changeset (hours/days); time to merge a fix into all supported versions; share of changes linked to a work item.
- Unit: hours; days; %.
Five-level table#
| Level | Short name | Promise | Typical indicator (orders of magnitude) |
|---|---|---|---|
| 1 | Copies | You can retrieve an old version, at the cost of manual searching. | Folder copies; no reliable history |
| 2 | Versioned | Each change is dated, attributed, and described, and each delivery is identifiable. | Complete history; tag per version |
| 3 | Linked | Each change is linked to its request, and a fix is ported to supported versions in less than one day. | ≥ 90% links; porting ≤ 1 day |
| 4 | Short | Changes are integrated in small batches: divergence is measured in hours, not weeks. | Median branch age < 2 days; rare conflicts |
| 5 | Smooth | The main line is always releasable; version variants cost almost nothing to maintain. | Daily integration; automated porting; ≈ 0 undetected semantic conflicts |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| DL-GIT-1.1 | Source code is under centralized version control | No source files “outside the repository” |
| DL-GIT-1.2 | Deliveries are identifiable (tag, changeset, number) | Retrieve the exact source of a delivered version in < 1 h |
| DL-GIT-1.3 | Repository access rights are assigned by name | Access review |
| DL-GIT-2.1 | Each change has a usable message (what + why) | Sample of 30 reviewed messages |
| DL-GIT-2.2 | The naming convention for branches and tags is written down | Document; compliance on sample |
| DL-GIT-2.3 | A repository backup is restoration-tested | Successful restoration < 12 months |
| DL-GIT-2.4 | Large binary files are handled separately | Exclusion rule/dedicated storage |
| DL-GIT-3.1 | ≥ 90% of changes are linked to a work item | Query on the tracking tool |
| DL-GIT-3.2 | The main line is protected: no direct push, mandatory review policy | Direct push attempt rejected |
| DL-GIT-3.3 | A fix is ported to each supported version in ≤ 1 business day | Measurement on the last three fixes |
| DL-GIT-3.4 | The branching strategy (by version, by feature, trunk) is chosen, written, and justified | Page describing the choice and its limits |
| DL-GIT-3.5 | Deliverable versioning follows a consistent rule (e.g., semantic) | Readable rule; consistent numbers |
| DL-GIT-4.1 | The median age of a feature branch is < 2 days and tracked | Weekly report |
| DL-GIT-4.2 | Unfinished work is hidden by feature toggles rather than long-lived branches | Toggles listed with removal date |
| DL-GIT-4.3 | Merge conflicts are rare and merges are tested before integration | Measured conflict rate; CI on merge |
| DL-GIT-4.4 | History is usable (small atomic changes, no “grab bag” commits) | Median change size < 200 lines |
| DL-GIT-5.1 | The main line is releasable at any time (daily integration) | Successful release of a randomly selected commit |
| DL-GIT-5.2 | Fix porting between versions is tooled (cherry-pick or assisted merge) with consistency checks | Log of automated porting |
| DL-GIT-5.3 | End-to-end traceability links requirement → change → test → delivery → deployment | Audit trail in < 15 min |
| DL-GIT-5.4 | Branch debt (dead branches, unused tags) is periodically cleaned up | Number of inactive branches > 60 days ≈ 0 |
Detailed reading by level#
🟢 Level 1 — Copies#
- Signs:
Project_v3_final_OK2. You do not know what is in production. A fix is redone manually. - Gain: no learning required.
- Does not guarantee: rollback, attribution, multi-person collaboration.
- Difficulty: 1/5 · Effort: 1/5.
🟢 Level 2 — Versioned#
- Signs: every change is dated and attributed; the delivered version is traceable.
- Gain: rollback is possible, audit is simple.
- Does not guarantee: the link to the “why,” integration speed.
- Difficulty: 1/5 · Effort: 2/5.
🟡 Level 3 — Linked#
- Signs: the change ↔ request link is standard; the main line is protected; fixes move between versions without re-entry.
- Gain: audits, release notes, and impact analyses become queries, not investigations.
- Does not guarantee: small batches — you can perfectly trace very large changes.
- Difficulty: 3/5 · Effort: 3/5.
🔴 Level 4 — Short#
- Signs: changes are integrated in under two days; unfinished work stays invisible thanks to feature toggles rather than branches. This practice is trunk-based development (trunk-based development), which requires fast and reliable testing.
- Gain: merging stops being an event; batches are small and therefore low risk.
- Does not guarantee: no toggle debt (a forgotten toggle is dead code path).
- Difficulty: 4/5 · Effort: 4/5.
🔴 Level 5 — Smooth#
- Signs: the main line is continuously releasable; a fix reaches all supported versions through a tooled process; full traceability allows an audit in minutes.
- Gain: multi-version maintenance at near-constant cost.
- Does not guarantee: that the number of supported versions is sustainable — that is a product lifecycle management decision.
- Difficulty: 5/5 · Effort: 4/5.
Partial achievement and rating#
Apply the rating rule.
- 0.5 on DL-GIT-3.1: 60 to 89% of changes linked.
- 0.5 on DL-GIT-3.3: porting to supported versions takes 2 to 3 days.
- A partial 5: the main line is releasable most of the time, but only one of the two fix flows is tooled.
“Temporary” branch forever. Symptom: a 6-week feature branch. Cause: scope is too large to deliver in one shot. Remedy: split into releasable increments behind a toggle.
Unreadable history. Symptom: messages like “fix,” “modif.” Cause: no control. Remedy: message template enforced by review (what, why, link).
Measure the age of the oldest unintegrated change. A single 30-day change often illustrates the problem better than the median.
Enforcing “one branch = one day max” encourages merging unfinished code without a toggle. Keep the goal on divergence risk, not duration alone.
Move to the next level#
Possible means (optional)
- 1 → 2: adopt a source control tool, ban folder copies as a versioning method.
- 2 → 3: link each change to a request (repository policy rule), protect the main line, write the branching strategy.
- 3 → 4: feature toggles, merge tested in CI before integration, short reviews.
- 4 → 5: tooling for porting between versions, periodic cleanup, end-to-end traceability audit.
A fix affecting a datamart procedure must reach three supported versions. At level 2, four hours of manual copies and one miss on the oldest version. At levels 3–4, assisted porting from the main line to the three version branches, each tested by its CI, in 40 minutes.
See also#
- Neighbors: 03 Testing · 05 CI · 06 Deployment · 12 Developer Experience and Flow.
- Other matrices: Project — Delivery and Production Release (LIV) · BI — Report Versioning and Industrialization.
- Practice: Git In Depth · TFVC In Depth · Git vs TFVC: Compare, Migrate, and Coexist · Branching Strategies · CI/CD: Continuous Integration and Delivery.
- Glossary · Rating: How to Read Scores, Ratings, and Legend.
✻ Written by Claude Sonnet 5.5
