Workflow Guide

I Lifehack-projektet skal I arbejde sammen om at udvikle en fælles webapplikation. Når flere udviklere arbejder på samme projekt, er det vigtigt, at nye features kan udvikles og testes, uden at det påvirker de øvrige udvikleres arbejde. Derfor skal I anvende feature branches og Pull Requests som en fast del af jeres udviklingsproces. Workflowet skal sikre:

• At flere udviklere kan arbejde parallelt.
• At ændringer gennemgås, inden de integreres.
• At main indeholder en fungerende version af applikationen.
• At alle teammedlemmer får indsigt i hinandens kode.
• At ændringer kan spores tilbage til konkrete opgaver.

I skal anvende følgende workflow:

GitHub Issue
     |
     v
Opret feature branch
     |
     v
Implementer feature (~user story)
     |
     v
Test lokalt
     |
     v
Commit og push
     |
     v
Opret Pull Request
     |
     v
Code review
     |
     v
Ret eventuelle fejl
     |
     v
Godkend Pull Request
     |
     v
Merge til main
     |
     v
Opdater lokal main

En feature betragtes først som færdig, når den er integreret i main og opfylder projektets Definition of Done.

Vi holder main stabil. I må aldrig commite direkte til main branch. main branch skal altid være indeholde clean, working, fejlfri kode.

Når I begynder på en ny opgave, skal I oprette en feature branch. Start med at kontrollere jeres lokale repository:

git status

Hvis der ikke er lokale ændringer, som skal håndteres, kan I skifte til main:

git checkout main

Opret derefter en feature branch.

Eksempel:

git checkout -b team-a/12-add-quote

Navngivning:

team/<issue-nummer>-<beskrivelse>

Branchens navn skal gøre det nemt at se, hvilken opgave der arbejdes på.

Commit Small and Often

Mens I udvikler en feature, skal I løbende committe jeres ændringer. Et commit skal repræsentere en meningsfuld ændring.

Eksempel:

git add .
git commit -m "Add quote controller"

Senere:

git add .
git commit -m "Add quote validation"

Det er bedre at lave flere meningsfulde commits end ét stort commit med alle ændringer.

Første gang:

git push -u origin team-a/12-add-quote

Efterfølgende:

git push

Ved at pushe løbende sikrer I, at jeres arbejde også ligger på GitHub (som backup og vidensdeling)

Når en feature er implementeret og testet lokalt, skal I oprette en Pull Request. En Pull Request er en anmodning om at integrere ændringerne fra jeres feature branch i main.

Gå til GitHub repository, click “Compare & pull request”, udfyld template og bed mindst ét andet teammedlem omat gennemgå ændringerne.

I må ikke selv godkende jeres egen Pull Request. reviewer.

Når en Pull Request er godkendt, kan den merges til main.

I Lifehack-projektet anvender vi: Squash and merge.

Det betyder, at alle commits på feature branchen samles i ét commit på main.

Eksempel:

Feature branch:

Add QuoteController
Add quote validation
Fix quote form
Improve error message

           │
           ▼
      Squash and merge
           │
           ▼

main:

Add quote creation feature

Det giver en mere overskuelig historik på main. Efter merge skal feature branchen slettes på GitHub.

Når en Pull Request er blevet merget, skal alle udviklere hente den seneste version af main.

Kontroller først jeres status:

git status

Hvis arbejdsområdet er rent:

git checkout main
git pull origin main

Når I opretter den næste feature branch, skal det ske fra denne opdaterede main. Det mindsker risikoen for konflikter og sikrer, at I udvikler videre på den seneste version af applikationen.

Git kan normalt merge ændringer, selvom en feature branch er flere dage gammel (hvilket den normalt ikke bør være, men ting sker …).

Problemet opstår oftest, hvis de forskellige teams har ændret de samme dele af koden.

Eksempelvis:

• Main.java
• pom.xml
• Fælles CSS-filer
• Fælles Thymeleaf-templates
• Databasekonfiguration
• Routing og controllerregistrering

Jo længere tid en feature branch eksisterer, desto større er sandsynligheden for, at den kommer i konflikt med ændringer fra andre teams. Det er ikke nødvendigvis antallet af dage, der er problemet, men hvor meget fælles kode der ændres i perioden.

Arbejd derfor med små, kortlivede feature branches, som integreres hyppigt.

Mem hvis der opstår en merge konflikt, bør du løse den lokalt på din maskine og ikke online:

1. Skift til din feature branch: git checkout feature/your-feature-name
2. Pull seneste main ind i feature branch: git pull origin main
3. Åben de filer, som er i konflikt i din editor (IntelliJ). Se efter konfliktmarkeringer: (<<<<<<<, =======, >>>>>>>).
4. Snak med de andre i dit team (og evt. amdre teams) for at løse forskellene, fjerne markeringer, save, og commit:

   git add .
   git commit -m "Resolve merge conflict with main"
   git push origin feature/your-feature-name
   

Pull Request vil automatisk opdateres på GitHub!