bcquality/custom/knowledge/architecture/feature-branch-must-merge-to-track-branch.md
Michael Dieringer dd5637b1db Custom-laget bestaar nu begge CI-checks: 72 validator-fejl -> 0
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens
skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne):

- R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer
  (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6
  kraevede noegler; keywords haandskrevet pr. fil da de driver
  worklist-selektionen i INDEX/knowledge-index
- R09: manglende Description-sektion - regel-agtige foersteoverskrifter
  (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat
  efter titlen hvor intro-tekst fandtes
- R10: fenced code blocks konverteret til 4-space indrykkede blokke
  i alle filer (indhold uaendret)
- R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk
  tab (ai-eval-scores 143->100, git-lifecycle 121->97,
  permission-sets 113->99, test-feature-scenario-tags 105->91)
- R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet
  til maks 10

Ingen regler er fjernet eller aendret i betydning - kun form.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-01 23:47:31 +02:00

74 lines
2.3 KiB
Markdown

---
bc-version: [all]
domain: architecture
keywords: [git, feature-branch, track-branch, merge, workflow]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Feature branches must merge into the project's declared track branch
## Description
When a project declares a track branch in `CLAUDE.md`, all feature branches
MUST merge into that track branch — not into `main` directly. `main` is
reserved for releases and hotfixes.
## Track branch declaration
The track branch is declared once in `CLAUDE.md`:
# Declares the integration target for this development sprint/module
trackBranch: purchase
If no `trackBranch` is declared, `main` is the default and feature branches
merge there directly.
## Why
In multi-module or multi-sprint projects, a named track branch acts as an
integration buffer:
| Without track branch | With track branch |
|---|---|
| Every feature branch merges to `main` | Features collect on track branch |
| `main` accumulates partial, in-flight work | `main` stays clean for hotfixes |
| A hotfix requires reverting or cherry-picking | A hotfix branches from `main` unaffected |
The rule protects the invariant: **`main` is deployable at any moment.**
## Merge requirements
1. Feature branch must compile and pass before merge
2. Merge uses `--no-ff` to preserve branch history in the log
3. After merge: BC dev status is set to `Done` (see `[[git-lifecycle-must-sync-bc-status]]`)
## The branching model
main
└── <track-branch> (e.g. "purchase" — lives for one sprint/module)
└── feature/<name> ← development happens here
└── feature/<name>
└── bugfix/<name>
└── hotfix/<name> ← branches from main, merges back to main
At release: track-branch → main (via PR, after full QA).
## Non-compliant
# Merging a feature directly to main when a track branch is declared in CLAUDE.md
git checkout main
git merge feature/my-feature # violates rule
## Compliant
# Read track branch from CLAUDE.md → merge there
git checkout purchase
git merge --no-ff feature/my-feature
# Then sync BC: gitHubDevStatus = "Done"
## Scope
Applies to every CURABIS project with a `trackBranch` declaration in `CLAUDE.md`.
Projects without a declaration use `main` as the track branch — no change needed.