Git och repos – spara historik och samarbeta

Kort sagt

Git är ett verktyg som håller reda på ändringar i filer. Du kan spara tydliga steg i arbetet, se vad som ändrats och samarbeta utan att skapa filer som heter slutlig-version-7-verkligen-slutlig.

Ett repo, kort för repository, är projektets versionshanterade samling av filer och historik. GitHub är en tjänst där du kan lagra och samarbeta kring repos. Git och GitHub är alltså inte samma sak – Git fungerar även lokalt, utan internet.

Se instruktionsfilmen

Filmen går igenom övningen med två commits och förklarar utvecklingsgrenar. Se filmen i videogalleriet eller använd spelaren längre ner på sidan. Pausa när du provar kommandona.

Ett exempel: en webbplats

Illustration: Du bygger en liten webbplats. Först finns en startsida. Sedan lägger du till kontaktuppgifter. Till sist förbättrar du menyn.

Med Git kan du spara tre tydliga steg:

Startsidans första version → Lägg till kontaktuppgifter → Gör menyn lättare att använda.

Varje sparat steg kallas en commit. Den representerar ett sparat tillstånd för de versionshanterade filerna, med ett meddelande och koppling till tidigare historik. Du kan jämföra stegen och se exakt vilka ändringar som gjorts.

Git passar särskilt bra för kod, Markdown och andra textfiler. Bilder och dokument kan också lagras, men är ofta svårare att jämföra och slå ihop. Stora binära filer kan behöva särskild hantering.

Begreppen på en sida

Begrepp	Enkel förklaring
Repo	Projektets filer och Git-historik.
Commit	Ett sparat steg i historiken.
Staging	Urvalet av ändringar som ska ingå i nästa commit.
Branch	En namngiven utvecklingslinje där du kan arbeta vidare.
Merge	Att förena ändringar från olika utvecklingslinjer.
Remote	Ett namngivet annat repo, ofta på en server.
Clone	Att skapa en lokal kopia av ett befintligt repo, med historik.
Push	Att skicka lokala commits till ett remote-repo.
Pull	Att hämta och integrera ändringar från ett remote-repo.
Pull request	Ett förslag till ändringar som andra kan granska på exempelvis GitHub.

En branch är inte en fullständig kopia av projektmappen. Tänk en etikett på en utvecklingslinje. När du byter branch uppdaterar Git normalt vilka filer du ser i arbetsmappen.

Spara filen är inte samma sak som en commit

Det finns tre steg:

1. Arbetsmappen: Du redigerar och sparar en fil som vanligt.
2. Staging: Du väljer vad nästa commit ska innehålla.
3. Historiken: Du gör en commit som sparar det valda tillståndet.

En commit är lokal. Den skickas inte automatiskt till GitHub. Och en push gör inte automatiskt din webbplats publik – det krävs ett separat publiceringsflöde, även om det ibland startas automatiskt av en push.

Prova i en ny övningsmapp

Använd en tom övningsmapp, inte ett befintligt arbetsprojekt. Git behöver vara installerat. Öppna terminalen i övningsmappen och starta repot:

git init -b main

Skapa sedan filen README.md i övningsmappen med texten # Mitt projekt, med en vanlig textredigerare.

Om du inte redan har en författaridentitet i Git, konfigurera den för just detta övningsrepo. Ersätt exempelvärdena med det namn och den e-postadress du vill använda:

git config --local user.name "Ditt namn"
git config --local user.email "din-adress@example.com"

E-postadressen följer med commit-historiken och kan bli synlig om repot delas. På GitHub kan du använda din GitHub-provided noreply-adress om du vill skydda din privata adress. Inställningen ovan gäller bara detta repo.

Granska och spara därefter din första commit:

git status
git add README.md
git diff --cached
git commit -m "Lägg till projektbeskrivning"
git log --oneline

• init gör övningsmappen till ett Git-repo.
• status visar vad som är ändrat och ännu inte sparat i historiken.
• add väljer filens nuvarande innehåll till nästa commit; det publicerar ingenting.
• diff --cached visar det valda innehållet innan du sparar steget.
• commit sparar steget. Git kan be dig konfigurera namn och e-post för commitens författare.
• log visar historiken.

Ändrar du filen efter add behöver du välja den nya ändringen igen om den ska ingå. Det går också att välja delar av en fil, men börja med en fil i taget.

Så samarbetar ni

Illustration: Du vill förbättra webbplatsens meny utan att blanda in halvfärdigt arbete i huvudlinjen.

1. Hämta projektet. Klona repot till din dator.
2. Skapa en branch. Ge den ett namn som beskriver arbetet, exempelvis tydligare-meny.
3. Gör små commits. Spara sammanhängande ändringar med tydliga meddelanden.
4. Dela för granskning. Pusha branchen till rätt remote och öppna en pull request.
5. Granska och testa. Kontrollera förändringen innan den slås ihop med huvudlinjen.

Om två personer ändrat samma del av en fil kan Git behöva hjälp. Det kallas en mergekonflikt: ni behöver bestämma vilket innehåll som ska finnas kvar. Det är inte ett tecken på att projektet är förstört.

Checklista före en commit eller push

• Jag har tittat på git status och granskat ändringarna.
• Commiten innehåller en sammanhängande förändring.
• Jag har inte lagt till lösenord, API-nycklar eller privata uppgifter.
• Jag vet vilket repo och vilken branch jag arbetar i.
• Innan push: jag vet vart ändringarna skickas och vem som kan se dem.

Viktigaste fallgropen

Att tro att Git sparar allt automatiskt eller ersätter en säkerhetskopia. Ändringar som inte finns i en commit är inte sparade i commit-historiken. En lokal commit skyddar inte mot att datorn försvinner.

En .gitignore kan hindra vissa ospårade filer från att läggas till av misstag, men tar inte bort hemligheter som redan hamnat i historiken. Om en API-nyckel läckt behöver den spärras eller bytas – att bara radera filen räcker inte.

Vad du kan göra nu

Skapa ett övningsrepo med en README. Gör en commit, ändra en mening och gör en till. Jämför ändringarna och förklara skillnaden mellan att spara en fil, göra en commit och pusha till ett remote.