Git Workflow Mastery – Parprogrammeringsövning

Tidsåtgång: 4–5 timmar
Arbetssätt: Två personer, driver/navigator-rotation
Fokus: Git-workflow, commits, branches, rollback, merge-konflikter

Syfte

Övningen kombinerar grundläggande webbutveckling (HTML/CSS/JavaScript) med avancerad Git-hantering. Ni bygger en enkel webbapplikation samtidigt som ni övar på branching, meningsfulla commits, rollback-strategier och konfliktlösning.

Förberedelser (15 min)

Initial setup

1. En person skapar ett nytt Git-repository lokalt
2. Skapa ett remote "bare" (tomt, ingen readme) repository på GitHub (public)
3. Lägg till sökvägen till remote repot lokalt via git add URL-till-repot
4. Pusha till remote
5. Den andra personen klonar repository

Baseline-struktur

Skapa följande filer på main branch:

project-root/
├── index.html (minimal struktur)
├── styles.css (tom eller minimal)
├── app.js (tom eller minimal)
└── README.md (projektbeskrivning)

Gör initial commit: "init: project baseline with base files"

Commit-policy

Ni ska följa dessa regler genomgående:

• Imperativ form: "add", "fix", "refactor", "feat"
• Prefix med typ: feat:, fix:, refactor:, chore:
• Kortfattad första rad (max 72 tecken)
• Längre beskrivning vid behov efter tom rad (Kolla hur man gör detta i Git dokumentationen)
• En logisk enhet (sak, funktion) per commit

Rollfördelning

• Driver: skriver kod
• Navigator: granskar, diskuterar, guidar
• Växla roll var 20–30 min

Projektbeskrivning

Ni ska bygga en Task Manager med följande funktioner:

• Header med titel och navigering
• Formulär för att lägga till task (titel + prioritet)
• Lista som visar tasks
• Möjlighet att markera task som klar
• Möjlighet att ta bort task
• Filtrering: visa alla/aktiva/klara
• Responsiv design (mobile-first)

Tidsplan och steg

Del 1: Layout och struktur (45 min)

Branch: feature/layout

1. Skapa och checka ut branch
2. Implementera HTML-struktur:
   • Semantiska element (header, main, section, footer)
   • Form med input-fält och button
   • Container för task-lista
3. Gör minst 3 separata commits:
   • feat: add header and navigation structure
   • feat: add task input form
   • feat: add task list container
4. Push branch till remote
5. Merge till main (via PR eller lokalt)

Checkpoint: Verifiera att main har uppdaterats korrekt

---

Del 2: Grundläggande styling (45 min)

Branch: feature/base-styles

1. Skapa och checka ut ny branch från main
2. Implementera:
   • CSS-reset eller normalize
   • Grundläggande typografi och färgschema
   • Layout för form och lista
   • Button-styling
3. Gör minst 4 commits med meningsfulla meddelanden
4. Introducera avsiktligt fel: I sista commit, lägg till CSS som förstör någon layout (t.ex. body { display: none; })
5. Push branch
6. Merge till main

Checkpoint: main innehåller nu ett fel som ni ska åtgärda senare

---

Del 3: Responsiv design (40 min)

Branch: feature/responsive

1. Skapa branch från main (inkluderar felet)
2. Implementera:
   • Mobile-first approach
   • Media queries för tablet/desktop
   • Flexbox eller Grid för layout
3. Testa i olika skärmstorlekar
4. Gör 3–4 commits
5. Push branch (merge EJ än)

Vänta med merge

---

Del 4: JavaScript-funktionalitet (50 min)

Branch: feature/task-logic

1. Skapa branch från main
2. Implementera JavaScript:
   • Lägg till task
   • Visa tasks i DOM
   • Markera som klar (toggle)
   • Ta bort task
   • LocalStorage för persistens
3. Dela upp i små logiska commits:
   • feat: add task creation logic
   • feat: implement task rendering
   • feat: add toggle complete functionality
   • feat: add delete task feature
   • feat: implement localStorage persistence
4. Push branch (merge EJ än)

Checkpoint: Nu har ni flera branches redo att mergas, plus ett fel i main

---

Del 5: Rollback-övning (30 min)

Mål: Åtgärda felet som introducerades i Del 2

Uppgift A: Identifiera problemet

1. Checka ut main
2. Öppna index.html i browser
3. Identifiera vilket fel som finns (layout förstörd)
4. Använd git log --oneline för att hitta commits från feature/base-styles

Uppgift B: Revert med git revert

1. Identifiera commit-hash för den felaktiga commit
2. Använd: git revert <commit-hash>
3. Testa att felet är åtgärdat
4. Push till remote

Uppgift C: Alternativ metod (demonstrera skillnad)

1. Skapa en test-branch: test/rollback-experiment
2. Använd git reset --hard HEAD~1 för att gå tillbaka
3. Observera skillnaden mot revert
4. Diskutera: När är reset lämpligt vs revert?
5. Ta bort test-branch

---

Del 6: Merge med konflikt (45 min)

Mål: Skapa och lösa en merge-konflikt

Setup: Förbered konflikt

1. Checka ut feature/responsive

2. Ändra <h1> i index.html till: <h1>Task Manager Pro</h1>

3. Commit: fix: update application title

4. Push branch

5. Checka ut feature/task-logic

6. Ändra samma <h1> till: <h1>My Task Dashboard</h1>

7. Commit: feat: personalize app title

8. Push branch

Merge och lös konflikt

1. Checka ut main
2. Merge feature/responsive (bör gå smidigt)
3. Försök merge feature/task-logic
4. Konflikt uppstår!

Konfliktlösning

1. Kör git status för att se konfliktfiler
2. Öppna index.html och hitta konfliktmarkörer:

   <<<<<<< HEAD
   <h1>Task Manager Pro</h1>
   =======
   <h1>My Task Dashboard</h1>
   >>>>>>> feature/task-logic
   

3. Välj en lösning (eller kombinera): <h1>Task Manager – Dashboard</h1>
4. Ta bort konfliktmarkörer
5. Testa i browser
6. Stage: git add index.html
7. Commit: git commit (meddelande genereras automatiskt)
8. Push till remote

Checkpoint: Konflikt löst, båda branches mergade

---

Del 7: Filtrering och förfining (40 min)

Branch: feature/filter

1. Skapa branch från uppdaterad main
2. Implementera filtrering (visa alla/aktiva/klara tasks)
3. Lägg till knappar eller radio buttons för filter
4. Uppdatera rendering-logik
5. Gör 3 commits
6. Push och merge till main

---

Del 8: Commit-hygien (30 min)

Mål: Städa commit-historik med interaktiv rebase

Uppgift: Squash commits

1. Skapa ny branch: feature/polish
2. Gör några små förbättringar (CSS-tweaks, kommentarer i kod)
3. Gör 4–5 små commits (simulera "work in progress")
4. Använd interaktiv rebase för att squash:

   git rebase -i HEAD~5

5. Squash alla commits till 2 meningsfulla commits
6. Force-push: git push --force-with-lease

Diskussion

• Varför force-push?
• När är det säkert att omskriva historik?
• Varför --force-with-lease istället för --force?

---

Del 9: Pull Request och review (20 min)

1. Skapa en sista feature-branch: feature/final-touches
2. Gör små förbättringar (README, kommentarer, styling)
3. Push branch
4. Skapa Pull Request på GitHub med:
   • Beskrivande titel
   • Detaljerad beskrivning av ändringar
   • Checklist (om relevant)
5. Den andra personen granskar PR:
   • Kommentera på kod
   • Begär ändringar eller approva
6. Merge PR (välj squash-merge eller merge-commit)

---

Del 10: Release och tagging (20 min)

Mål: Skapa en formell release av projektet med versionstag och release notes

Bakgrund: Vad är en Release?

En Git tag är en märkning av en specifik commit (som ett bokmärke i historiken).
En GitHub Release är ett paket som innehåller:

• Taggen
• Automatiska nedladdningslänkar (zip/tar.gz av koden)
• Release notes (beskrivning av vad som är nytt/ändrat)
• Valfritt: bifogade filer (binärer, assets)

Varför? En release markerar en stabil version av projektet och gör det lätt för andra att hitta och ladda ner specifika versioner.

Steg 1: Förbered main branch

1. Checka ut main:

   git checkout main

2. Pull senaste ändringar:

   git pull

3. Verifiera att allt fungerar i browser
4. Kontrollera commit-historik:

   git log --oneline -10

Steg 2: Skapa en tag lokalt

1. Skapa en annotated tag (rekommenderat för releases):

   git tag -a v1.0.0 -m "Release: Task Manager v1.0.0 - Initial stable version"

   • -a = annoterad tag (innehåller metadata)
   • v1.0.0 = versionsnamn (följer Semantic Versioning: MAJOR.MINOR.PATCH)
   • -m = meddelande

2. Verifiera att taggen skapades:

   git tag
   git show v1.0.0

Steg 3: Pusha taggen till remote

git push --tags

eller specifikt för en tag:

git push origin v1.0.0

Resultat: Taggen syns nu på GitHub under "Tags" (bredvid "Branches")

Steg 4: Skapa Release på GitHub

1. Navigera till repository på GitHub

2. Klicka på "Releases" (höger sidebar under "About", eller via huvudmenyn)

3. Klicka "Create a new release" eller "Draft a new release"

4. Fyll i Release-formuläret:

   Choose a tag:

   • Välj v1.0.0 från dropdown (den tag ni precis pushade)

   Release title:

   Task Manager v1.0.0
   

   Describe this release: Skriv release notes i Markdown-format. Exempel:

   ## ✨ Features
   - ✅ Add, complete, and delete tasks
   - 🎯 Filter tasks by status (all/active/completed)
   - 💾 Automatic save with LocalStorage
   - 📱 Fully responsive design (mobile-first)
   
   ## 🛠️ Technical Details
   - Vanilla JavaScript (no frameworks)
   - Semantic HTML5
   - Mobile-first CSS with Flexbox
   - Persistent storage via LocalStorage
   
   ## 🚀 Installation
   1. Download source code (zip below)
   2. Open `index.html` in a modern browser
   3. Or serve via local server: `python -m http.server`
   
   ## 📝 Known Issues
   None at this time.
   
   ## 👥 Contributors
   - [Ditt namn]
   - [Din partners namn]

5. Valfritt: Bifoga filer

   • Om ni hade kompilerade filer, bilder, eller andra assets kan ni dra och släppa här
   • För denna övning: hoppa över

6. Pre-release?

   • Låt vara avbockad (detta är en stabil release)
   • Skulle användas för beta/alpha-versioner

7. Klicka "Publish release"

Steg 5: Verifiera Release

1. På GitHub:

   • Releasen syns under "Releases"
   • Automatiska nedladdningslänkar för "Source code (zip)" och "Source code (tar.gz)" finns

2. Lokalt:

   git fetch --tags
   git tag -l

3. Testa nedladdning:

   • Klicka på "Source code (zip)" på GitHub
   • Packa upp och öppna index.html för att verifiera

Diskussion (5 min)

Reflektera tillsammans:

• Vad är skillnaden mellan en tag och en release?

  • Tag: En Git-referens till en specifik commit
  • Release: Ett GitHub-koncept som paketerar en tag med metadata och filer

• När skapar man en release?

  • Vid varje stabil version (1.0.0, 1.1.0, 2.0.0)
  • Vid bugfix-releases (1.0.1)
  • Inte för varje commit eller feature

• Vad är Semantic Versioning?

  • MAJOR (1.0.0 → 2.0.0): Breaking changes (inkompatibla ändringar)
  • MINOR (1.0.0 → 1.1.0): Nya features (bakåtkompatibla)
  • PATCH (1.0.0 → 1.0.1): Bugfixes (bakåtkompatibla)

Nästa steg (valfritt)

Om tid finns kvar:

1. Skapa en hotfix:

   • Hitta en liten bugg
   • Fixa på branch hotfix/1.0.1
   • Merge till main
   • Skapa tag v1.0.1 och ny release

2. Experimentera:

   • Skapa en pre-release (t.ex. v1.1.0-beta.1)
   • Testa att checka ut en specifik tag:

     git checkout v1.0.0

   • Återgå till main:

     git checkout main

Checkpoint: Ni har nu en officiell v1.0.0 release med automatiska nedladdningslänkar och dokumentation!

---

Retrospektiv (15 min)

Diskutera och dokumentera:

Vad fungerade bra?

• Vilka Git-kommandon kändes naturliga?
• Hur fungerade kommunikationen i parprogrammeringen?

Vad var utmanande?

• Vilka Git-koncept var svåra?
• Vilka konflikter uppstod (tekniska eller samarbete)?

Nästa steg

• Vilka Git-färdigheter vill ni utveckla mer?
• Hur kan ni tillämpa detta i framtida projekt?

Acceptance-kriterier

• Task Manager fungerar enligt spec i browser
• Minst 15 meningsfulla commits i historiken
• Genomfört minst en git revert framgångsrikt
• Löst minst en merge-konflikt manuellt
• Använt interaktiv rebase för att städa historik
• Skapat och mergat Pull Request
• Taggat release (v1.0.0)
• Dokumenterat retrospektiv

Tekniska krav

HTML

• Semantiska element
• Accessibility (ARIA labels där relevant)
• Valid HTML5

CSS

• Mobile-first design
• Minst 2 breakpoints
• Konsekvent naming (BEM eller annan konvention)

JavaScript

• Vanilla JS (inga ramverk)
• Event listeners
• LocalStorage
• Funktionell uppdelning (modulärt)

Git

• Meningsfulla branch-namn
• Commit-messages följer policy
• Använt: branch, merge, revert, rebase, tag

Troubleshooting

Problem: Merge-konflikt är för komplicerad

Lösning: Avbryt merge med git merge --abort och försök igen steg för steg

Problem: Force-push nekades

Lösning: Kontrollera att ni inte force-pushar till main (ska skyddas)

Problem: Lost commits efter rebase

Lösning: Använd git reflog för att hitta och återställa

Problem: LocalStorage fungerar inte

Lösning: Kontrollera att ni kör via http:// (inte file://) eller använd local server

Resurser

• Git Documentation
• Conventional Commits
• Interactive Rebase Tutorial

---

Lycka till! Detta är en självständig övning, ni löser problem tillsammans och konsulterar dokumentation vid behov.