Issues
Issues er jeres opgaveliste på GitHub — fra kundens bug til sprint-feature, helt til lukket via pull request og release.
Hvorfor bruger vi issues?
Uden issues forsvinder opgaver i chatten. Med issues har I struktur, ansvar og sporbarhed hele vejen fra idé til leverance.
- Fælles opgaveliste — Issues er teamets todo-liste på GitHub — alle kan se hvad der skal laves, hvem der arbejder på det, og hvad status er.
- Dialog med kunden — En bug fra kunden bliver til et issue med beskrivelse, prioritet og opfølgning — ikke en løs besked i chatten.
- Sporbarhed til kode — Via "Closes #42" i PRs kan I følge en ændring fra opgave → kode → release. Perfekt til sprint og dokumentation.
- Sprint-planlægning — Issues kan lægges på et GitHub Project board med kolonner som Todo, In Progress og Done — jeres digitale sprint-board.
Sådan arbejder vi med issues
Vaner der gør sprint og samarbejde med kunden forudsigeligt.
-
Ét issue per opgave
Opdel store features i mindre issues. "Byg hele appen" er ikke et issue — "Tilføj login-side" er.
-
Beskriv så andre forstår
En god issue har titel, beskrivelse, steps to reproduce (for bugs) og acceptance criteria (for features).
-
Tildel ansvar
Assign issue til den der arbejder på det. Så undgår I at to tager samme opgave.
-
Luk via PR — ikke manuelt
Brug "Closes #12" i PR-beskrivelsen så issue lukkes automatisk ved merge. Det holder boardet opdateret.
Issue → kode — visuelt
Følg issue #42 fra oprettelse til lukket via branch, PR og merge på main.
Klik på trinene og se issue #42 koblet til branch, PR og main
Issue oprettet
Bug eller feature dokumenteret som issue #42 på GitHub.
Issue-livscyklus
Fra oprettelse til lukket via PR — klik gennem trinene og følg issue #42.
Klik på trinene og se issue #42 fra oprettelse til lukket via PR
Login fejler når e-mailfelt er tomt
Ny issue på GitHub
GitHub → Issues → New issue. Vælg skabelon hvis I har en, skriv titel og beskrivelse. Tilføj labels (bug, enhancement) og milestone (sprint).
💡 Gode titler er specifikke: "Fix: validering af e-mail" frem for "Bug i form".
Issue-skabeloner
Bug, feature og chore har forskellig struktur. Vælg type og brug skabelonen.
Vælg issue-type og se skabelon til titel og beskrivelse
Noget virker ikke som forventet — fejl, crash, forkert adfærd.
Login fejler når e-mailfelt er tomt
## Beskrivelse Kort hvad der går galt. ## Steps to reproduce 1. Gå til /login 2. Lad e-mail stå tom 3. Klik "Log ind" ## Forventet adfærd Valideringsfejl vises. ## Faktisk adfærd App crasher / ingen fejlbesked. ## Relateret Sprint 3 · fundet af kunde
Kobl issues til PRs
Keywords i PR-beskrivelsen styrer om issue lukkes automatisk ved merge.
Closes #42 Lukker issue #42 når PR merges Fixes #42 Samme som Closes — lukker ved merge Resolves #42 Samme som Closes — lukker ved merge Relates to #42 Linker uden at lukke — til delvis arbejde Dårlige vs. gode issues
Kvalitet i issues sparer tid i review og sprint.
Bug Login fejler når e-mailfelt er tomt Titlen skal sige hvad der er galt — ikke bare "Bug".
Fix login Som bruger vil jeg se fejlbesked ved ugyldig e-mail Features beskrives som user stories med acceptance criteria.
(tom beskrivelse) Steps to reproduce + forventet/faktisk adfærd Uden steps kan ingen anden genproducere buggen.
Issue lukkes manuelt uden PR Closes #42 i merged PR Automatisk lukning sikrer sporbarhed fra issue til kode.
Fra issue til release
Issues er startpunktet i jeres workflow — koblet til branch, PR, merge og release.
Klik på hvert trin for at se forklaring og kommandoer
Opret opgave
Issues er udgangspunktet — bug, feature eller chore dokumenteres før kode skrives.
Trin-for-trin guide
Sådan opretter du et issue og lukker det via pull request.
Test din viden
Svar på spørgsmålene for at tjekke om du har styr på GitHub Issues.
Hvad er hovedformålet med GitHub Issues?
Hvordan lukkes et issue automatisk ved merge?
Hvad bør en bug-issue minimum indeholde?
Hvorfor bruge issue-nummer i branch-navn (fx fix/42-login)?
Hvad er forskellen på "Closes #42" og "Relates to #42"?