Committa — vad det är, formateringsregler och arbete med Git

Vad är en commit i Git

En commit i Git är ett objekt som lagrar tillståndet för projektets filer vid en given tidpunkt. Varje commit innehåller en ögonblicksbild av alla spårade filer, en referens till överordnad commit och metadata. Till skillnad från andra versionshanteringssystem använder Git content-addressable storage — varje objekt identifieras av SHA-1-hashen för dess innehåll.

När en utvecklare committar ändringar skapar Git ett commit-objekt som lagrar: tree-objekt (filstruktur), hash för överordnad commit, författare, committer, datum och meddelande. Detta objekt är oföränderligt — efter skapandet kan en commit inte modifieras utan att dess hash ändras. Just oföränderligheten garanterar integriteten i projektets historik.

# Förbered ändringar och committa
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Visa commitdetaljer
git log --oneline -3
git show HEAD

# Förbered alla ändringar och committa i ett steg
git commit -a -m "Update dependencies to latest versions"

Commits bildar en riktad acyklisk graf (DAG), där varje ny commit refererar till den föregående. Detta möjliggör navigering i historiken, återställning av ändringar och analys av kodbasens utveckling. Förståelse av strukturen Git DAG — grunden för avancerat arbete med commits.

Hur man committar ändringar korrekt

Commit-processen i Git består av två steg: att lägga till ändringar i staging area (index) och att skapa commit. Staging area tillåter utvecklaren att välja vilka ändringar som ska ingå i commit, även om många filer har ändrats i arbetskatalogen.

Atomicitetsregeln — den viktigaste principen för en bra commit. Varje commit bör innehålla en logisk ändring. Om utvecklaren fixar en bugg och refaktoriserar kod — är det två olika commits. Atomära commits förenklar kodgranskning, återställning av ändringar och historikanalys.

Innan man committar är det värt att kontrollera: om det finns kvar felsökningsutskrifter, kommenterade block eller oavsiktliga ändringar i koden. För detta används kommandot git diff --cached, som visar exakt vad som kommer att ingå i commit. Extra kontroll via git status visar listan över filer i staging area.

• Kontrollera ändringar — git diff --cached visar vad som ingår i commit
• Kontrollera kvalitet — kod bör passera linter och tester innan commit
• Skriv meddelande — begriplig beskrivning av ändringens syfte
• Kontrollera staged — git status bekräftar fillistan

Regler för att skriva commit-meddelanden

Commit-meddelandet är dokumentation av ändringen för framtida utvecklare. Ett bra meddelande besvarar frågorna: vad ändrades och varför. Konventionen Conventional Commits (Angular team, 2016) har blivit standard för många projekt och definierar formatet: typ(område): beskrivning.

Ett bra commit-meddelande består av en rubrik (upp till 50 tecken) och en brödtext (valfritt, upp till 72 tecken per rad). Rubriken skrivs i imperativ form: “Add” inte “Added” eller “Adds”. Versal och punkt i slutet av rubriken används inte — detta är den internationella Git-konventionen.

Dåligt meddelande: “fix things” eller “update” — bär ingen information. Om en månad kommer utvecklaren inte att kunna förstå vad som exakt ändrades och varför. Bra meddelande: “fix(payment): handle timeout in stripe callback” — omedelbart tydligt var och vad som fixades.

Vanliga misstag vid commits

Utvecklare, särskilt nybörjare, gör ofta typiska misstag vid commits. Det vanligaste — för stor commit där dussintals ändringar blandas. En sådan commit kan inte delvis återställas och kodgranskning blir ett lidande.

Det näst vanligaste misstaget — dåligt commit-meddelande. Meddelanden av typen “fix”, “update”, “changes” eller “wip” ger ingen kontext till framtida utvecklare. Om ett halvår kommer ingen att minnas vad som exakt fixades. Regeln är enkel: föreställ dig att du om ett år tittar i historiken och försöker hitta en specifik ändring.

Tredje misstaget — commit av okompilerad eller icke-fungerande kod. Efter commit bör koden åtminstone kompileras. Ej trasig build — grundläggande krav för varje commit till en gemensam gren. För detta körs bygge och tester innan commit.

Fjärde misstaget — commit med konfidentiell data. API-nycklar, lösenord och tokens bör inte hamna i Git-historiken. Om en hemlighet redan har committats räcker det inte att bara ta bort den i en ny commit — den måste tas bort från hela historiken via git filter-branch eller BFG Repo-Cleaner.

Avancerade tekniker för arbete med commits

Git tillhandahåller verktyg för att hantera commit-historiken. Ett av de mest användbara är git commit --amend, som tillåter att komplettera den senaste commit med nya ändringar eller korrigera meddelandet. Detta är praktiskt om utvecklaren glömde att inkludera en fil eller gjorde fel i meddelandet.

# Korrigera senaste commit-meddelandet
git commit --amend -m "fix(auth): correct token validation logic"

# Lägg till missad fil i senaste commit
git add missed-file.txt
git commit --amend --no-edit

# Interaktiv rebase för senaste 3 commits
git rebase -i HEAD~3

Interactive rebase — ett kraftfullt verktyg för att skriva om historik. Tillåter sammanslagning av commits (squash), ändring av meddelanden (reword), ändring av ordning (reorder) och borttagning av commits (drop). Rebase ändrar dock historiken, så det tillämpas endast på lokala commits som ännu inte har skickats till fjärrarkivet.

För att återställa commits finns två tillvägagångssätt. git revert skapar en ny commit som återställer den föregåendes ändringar — en säker metod som bevarar historiken. git reset tar bort commits från historiken — farligt om commits redan har skickats. I teamutveckling används endast git revert för att återställa publicerade commits.