Branch-strategi for GUI-utvikling

Sist endret: 2026-03-16 23:56av bruker: erikhag1git (Erik Hagen) ID: f2395d20-f21e-4ddd-86a7-f0fcb7599ec1 ◍Ny

Etter hvert som brukere tar nettstedet i bruk, bør aktiv GUI-utvikling skje i en separat branch slik at feil ikke forstyrrer produksjon. Inntil dette er satt opp, brukes main med rask tilbakerulling (se CI/CD-pipeline).

Foreslått oppsett

Brancher

RepoBranchFormål
hugo-theme-samt-budevGUI-endringer under utvikling
samt-bu-docsdevPeker på tema-dev, eventuelle konfig-endringer

Preview-URL

Cloudflare Pages bygger automatisk en preview-deploy for alle non-main branches:

dev.samt-bu-docs.pages.dev

Denne kan brukes til å teste hele edit-flyten (commit, build-polling, pending-indikator, OAuth) mot ekte GitHub – uten å berøre produksjonsinnhold på main.

Komplikasjon: commit-branch i JS

JS-koden i custom-footer.html committer til main som målbranch. På dev-branchen bør test-commits gå til dev, ikke main. Løsning: injiser commit-branch som en Hugo-parameter fra hugo.toml eller som en CI-miljøvariabel, slik at riktig branch brukes automatisk avhengig av hvilken branch som bygger.

Arbeidsflyt

  1. Gjør endringer i hugo-theme-samt-budev-branch
  2. Commit og push → CF Pages bygger preview
  3. Test hele edit-flyten på preview-URL
  4. Merge devmain i temaet når klar
  5. Oppdater submodule-peker i samt-bu-docs/main

Prioritet

Lav inntil videre – tilbakerullingsstrategien på main er tilstrekkelig for nåværende bruksmønster. Bør settes opp når GUI-endringene blir mer eksperimentelle eller brukerbasen vokser.