SWT Git Workflow Flashcards
Hvordan kan man undgå merge-konflikter, når man arbejder med Git?
En metode er f.eks. at lave branches
Hvad er alfa-release?
En version af systemet/produktet som vi sender ud til interne kunder (f.eks. os selv), hvor de prøver tingene igennem som om de var en slut-bruger
Hvad er beta-release?
En version af systemet/produktet som vi sender ud til eksterne brugere, som får lov til at afprøve det inden det bliver released, og giver os direkte feedback om fejl (og ikke igennem f.eks. Trustpilot).
Eksterne brugere er typisk en mindre grupper, som vi har en aftale med om at teste produktet
Hvorfor laver vi beta-release?
For at fange så mange fejl som muligt inden vi releaser. Vi kan ikke forudsige hvad brugeren gør, så derfor er det bedst bare at få brugeren til at teste.
Hvad er “the golden rule” om rebase?
Aldrig rebase publiserede branches (medmindre du ved hvordan du skal ‘force push’)
Hvad er User (Acceptance) Test ift. release?
En test, hvor brugere (eller andre udviklere, der agerer som brugere) har en tjekliste for at se, om vi har implementeret tingene korrekte og produktet kan, hvad det skal.
Hvad er en branch og hvorfor laver man det?
En lokal kopi af det, vi brancher ud fra (f.eks. main eller en anden branch). Det er ikke en fysisk kopi, selvom det ligner det for os som udviklere.
Man laver branches for ikke undgå at træde hinanden over tæerne konstant/undgå for mange merge-konflikter.
Hvad gør force push?
Det ændre noget i den historik, der allerede er skrevet, hvilket kan skabe problemer for andre udviklere. Force-push skal ringe alarmklokker. Hvis man får spørgsmålet om man vil “force push”, så brug “git revert”, der fjerner konfliktende ændringer, så vi kommer i samme tilstand som vi startede med.
Hvilke metoder bruges ofte til at integrere ændringer fra én branch til en anden?
“Merge” og “rebase”. Der findes også andre metoder, der er mindre populære, som f.eks. “merge squash”, “merge with forced fast-forward”, “merge with automatic fast-forward” osv.
Hvad bruger man “merge” eller “rebase” til, når man arbejder med Git?
Til at integrere ændringer fra én branch til en anden branch. Hertil er “merge” og “rebase” de to mest populære metoder.
Nævn nogle typer af Git workflow-udviklingsmodeller. Findes der et one-size-fits-all?
- Git-flow
- GitHub-flow
- Trunk-based flow
Der findes ikke nogen one-size-fits-all Git workflow model, men i praksis laves der ofte et mix af de tre ovenstående.
Hvad er et pull-request (PR)?
En forespørgsel for at få review på de ændringer, du har lavet på en branch, før du merger den sammen i en anden branch. Et andet ord for “pull-request” er “merge request”.
Det er en måde at indsende sit bidrag til et åbent udviklingsprojekt.
Hvad er de generelle guidelines for et godt Git workflow?
- Workflow bør være simpelt og forbedre produktiviteten
- Branches med kort levetid, ofte integration
- Aktivere kode-reviews og CI (continuous integration)
- Minimere og simplificere reverts
- Supporte en given release-model
Hvad er Trunk-based workflow?
.
Hvad er Feature-branch workflow?
.
