Tänk dig att du jobbar med en kodbas som du byggt i tre veckor. Du är trött, stressad, och i ett ögonblicks ouppmärksamhet glider fingret. Du raderar av misstag en stor del av koden. Muskelminnet tar vid innan hjärnan hinner reagera. Du trycker spara. Koden är borta.
Det är en specifik sorts modern panik. Förstärk den nu. Föreställ dig att det inte bara är du. Tio personer redigerar samma kodbas samtidigt. Någon raderar en kärnfunktion medan en annan skriver om gränssnittet. Någon ändrar databasstrukturen, och ni skriver alla över varandras arbete i realtid. Det är inte ett hypotetiskt kantfall — det är en matematisk säkerhet utan ett rigidt system på plats.
Git är det systemet.
Vad ett repository faktiskt är
När du skriver git init i en projektmapp händer något intressant som de flesta inte fullt uppfattar. Git skapar en dold katalog kallad .git inuti ditt projekt — och den katalogen är en databas. Ett övervakningssystem som spårar varje fil i ditt projekt från det ögonblicket, och kartlägger ett komplext matematiskt träd av projektets hela historia.
Det är mindre "en mapp på en server" och mer "en lokal databas som spårar kryptografiska hash av ditt arbete." Varje fil, varje ändring, varje radering, registrerad och indexerad.
Commits: sparpunkter med obligatoriska etiketter
Den grundläggande operationen i Git är commit:en — en permanent ögonblicksbild av din kod vid en specifik tidpunkt. Tänk på det som en sparpunkt i ett datorspel: innan du försöker refaktorera ett skört stycke gammal kod låser du in ditt framsteg så att du har en baslinje att retreata till om allt går sönder.
Det som förvirrar folk är den avsiktliga tvåstegsprocessen. Du kan inte bara "spara allt". Först stagar du specifika filer med git add. Sedan committar du med git commit. Varför friktionen?
Tänk på hur utvecklare faktiskt jobbar. Du spenderar fyra timmar på att skriva kod och rör sju olika filer. Tre av dem innehåller den lysande nya funktionen du ombads bygga. De övriga fyra innehåller röriga debug-utskrifter, temporära hack och trasiga experiment du använde för att testa. Du vill inte spara skräpet in i projektets officiella permanenta historia.
Tänk på stagingprocessen som fotografering. Den färdiga commit:en är att ta fotot. Stagingprocessen är där du arrangerar motivet, justerar belysningen och ser till att ingen blinkar. Du använder git add för att noggrant lägga bara de tre rena, färdiga filerna i bildramen. De röriga filerna stannar utanför bilden. Sedan skriver du en etikett på baksidan av polaroidfotot som förklarar exakt vad bilden föreställer.
Den etiketten spelar större roll än den verkar. En Git-historik är ett nät av sammankopplade ögonblicksbilder. När du eller ditt team blickar tillbaka om ett år och försöker hitta när ett specifikt fel uppstod, läser ni commit-meddelandena. "fixade saker" och "grejer" är inte navigerbara. "Refaktorerade autentiseringsmellanvaran för att hantera utgångna tokens" är det.
Branches: parallella universum till nästan noll kostnad
Branches löser multiplayer-kollisionsproblemet. När du vill bygga en ny funktion bygger du den inte i huvudtidslinjen. Du skapar ett parallellt universum med git checkout -b min-funktion, en helt isolerad version av kodbasen.
Det som förvånar de flesta: en branch är inte en kopia av ditt projekt. Om din kodbas är 2 gigabyte duplicerar inte en branch dessa 2 gigabyte. En branch är bokstavligen en 41-byte textfil som innehåller en pekare till din nuvarande commit. Att skapa den kostar nästan noll minne. Det skapar bara ett nytt klistermärke som säger "härifrån, registrera nya ögonblicksbilder på den här vägen."
Du kan förstöra all kod i din branch. Radera kärnfiler. Sätta hela grejen i brand. Huvudversionen av kodbasen, som resten av ditt team jobbar på, är helt isolerad och intakt. Experimentellt mod till nästan noll kostnad.
GitHub: det molnbaserade synkroniseringslagret
Allt som beskrivs ovan sker lokalt, inuti den dolda .git-katalogen på din maskin. GitHub är där nätverkslagret tar vid. Om Git är den lokala databasen är GitHub den centraliserade mastservern som håller sanningen för hela teamet.
git push origin main skickar dina commits från din maskin till det centrala repository:t. git pull hämtar de senaste ändringarna från alla andra till din maskin.
Protokollet: pull innan du börjar jobba. Skapa branch. Gör commits. Push när du är klar. Merge in i main. Arbetsflödet är vattentätt av en anledning: det är designat för att förhindra den typ av kollision som annars vore en matematisk säkerhet.
När AI tar över ratten
Stefan Sånnells ursprungstext för det här bootcampet avslutas med ett skifte värt att tänka på. Ett AI-verktyg som Claude Code kan abstrahera hela Git-arbetsflödet. Istället för att skriva kommandosekvensen själv beskriver du avsikten på vanlig svenska: "skapa en ny branch som heter fix-login-bug och committa mina ändringar."
AI:n analyserar din arbetskatalog, räknar ut vilka filer som ändrats, skapar branchen, stagar relevanta filer, genererar ett beskrivande commit-meddelande baserat på de faktiska kodändringarna, och kör commit:en.
Det löser problemet med meningslösa commit-meddelanden skrivna klockan tre på natten. Det demokratiserar verktyget för folk som inte har ett decennium av kommandoradsvana.
Men det finns en spänning värd att bära med sig. Git är inte bara syntax — det är tillståndshantering. Det är den arkitektoniska grunden för hela teamets samarbetshistoria. Om AI:n misstolkar din avsikt och stagar filer som innehåller känsliga API-nycklar för att du vagt sa "committa allt" och du inte granskade git add-steget, är det en katastrofal säkerhetsincident.
Den mentala modellen spelar fortfarande roll, även om du inte skriver kommandona. Du är chefen som delegerar till en skicklig assistent. Du måste veta vad du ska be om, och du måste kunna känna igen när något gått fel. Om vi är arkitekter eller passagerare beror helt på hur väl vi förstår vad som händer under ytan.