Git-Strategie

Monorepo

MATEV 2026 liegt als ein Monorepo auf Forgejo (git.matev.eu):

Repo	Inhalt
matev/matev-2026	Alles: admin, b2b, cms, staging, storybook, docs, shared, tools, deploy.php, .woodpecker.yml
matev/infra	Server-Stack-Config (~/stacks/git: Forgejo + Woodpecker Compose)

Historie: Früher war ein Multi-Repo mit Git-Submodules (admin/cms/staging/b2b/shared) geplant. Das wurde zugunsten eines flachen Monorepos aufgelöst — die .woodpecker.yml arbeitet pfadbasiert (admin/**, b2b/**, …) und funktioniert nur flach. Es gibt keine Submodules mehr.

Der matev-2026-Verlauf wurde einmalig verschlankt (ein 3,4-GB-Backup-Tarball via git-filter-repo aus docs/backups/ entfernt → ~30 MB). docs/backups/ ist per .gitignore ausgeschlossen und gehört nicht ins Git.

Branching-Modell

Drei langlebige Branches, kurzlebige Feature-Branches davor:

main ───────────────●───────────────●──────→  (Production: admin/vendor/bin/dep deploy production → 172.16.111.40)
                    ╱ (PR, nur aus staging, CI grün)
staging ──●────●───●────●────●──────→          (Test-/Integrations-Gate, KEIN Deploy)
         ╱        ╱         ╱
development ●───●────●────●──────→             (Integration aller Features)
           ╱
feature/  ●

Branch	Zweck	Deploy	Schutz
main	Produktions-Code	→ Production (172.16.111.40)	kein Direkt-Push; PR nur aus staging; CI (ci/woodpecker/*) muss grün
staging	Pre-Prod-Gate, Release-Kandidat	— (kein Staging-Server)	—
development	Integration der Features	—	—
feature/…, fix/…	Einzelne Änderungen	—	—

Wichtig: Es gibt nur einen Server (Production, 172.16.111.40). staging.matev.eu ist nur der öffentliche Proxy, kein Deploy-Ziel. staging ist deshalb ein reines Test-Gate vor main — dort laufen alle Pipeline-Checks, deployt wird aber nichts. Sobald es eine echte Staging-Umgebung gibt, kommt ein deploy-staging-Step in die Pipeline (Platzhalter-Kommentar steht schon in .woodpecker.yml).

Flow

1. Feature-Branch von development, arbeiten, PR → development (CI läuft).
2. development → staging mergen, wenn release-reif (CI = das Gate).
3. PR staging → main. Merge nur, wenn alle ci/woodpecker/*-Checks grün sind. Ein Guard-Step lehnt PRs nach main ab, deren Quelle nicht staging ist.
4. Merge nach main → Woodpecker-Step deploy-production → admin/vendor/bin/dep deploy production.

Branch Protection (main)

In Forgejo gesetzt (per API):

• Kein Direkt-Push (enable_push: false) — Änderungen nur via PR-Merge.
• Required Status Checks: ci/woodpecker/* muss grün sein.
• block_on_outdated_branch: Branch muss aktuell sein.
• Keine Pflicht-Approvals (required_approvals: 0) — das grüne CI ist das Gate (Solo-Setup).
• Guard im Pipeline-Step: PR nach main nur aus staging.

Bootstrap-Hinweis: Für direkte Config-Pushes auf main (vor Pipeline-Aktivierung) wird die Protection kurz per API entfernt, gepusht und wieder gesetzt.

Commit-Konventionen

Conventional Commits: <type>(<scope>): <beschreibung>.

Types: feat, fix, docs, style, refactor, test, chore, ci, perf, build.

Scopes:

Scope	Service
admin	Laravel 13 + Filament 5 (PIM)
cms	Kirby 4 + KQL
staging	Nuxt 4 Marketing-Frontend
b2b	Laravel 13 + Inertia 2 + Vue 3 (Händlerportal)
shared	YAML-Schemas + Vue-Komponenten
storybook	Design System
docs	VitePress
deploy / ci	Deployer / Woodpecker
infra	Server-Stack-Config (matev/infra)

CI

Jeder Push und jede PR löst die Woodpecker-Pipeline aus (ci.matev.eu, Forgejo-OAuth-Login als forgejo-admin). Pfadbasierte Trigger bauen nur geänderte Services. Details: Deployment.