Committen — wat het is, opmaakregels en werken met Git

Wat is een commit in Git

Een commit in Git is een object dat de status van projectbestanden op een bepaald moment opslaat. Elke commit bevat een snapshot van alle gevolgde bestanden, een verwijzing naar de parent-commit en metadata. In tegenstelling tot andere versiebeheersystemen gebruikt Git content-addressable storage — elk object wordt geïdentificeerd door de SHA-1 hash van de inhoud.

Wanneer een ontwikkelaar wijzigingen commit, maakt Git een commit-object aan dat bevat: tree-object (bestandsstructuur), parent-commit hash, auteur, committer, datum en bericht. Dit object is onveranderlijk — na aanmaak kan een commit niet worden gewijzigd zonder de hash te veranderen. Juist deze onveranderlijkheid garandeert de integriteit van de projectgeschiedenis.

# Wijzigingen klaarzetten en committen
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Commitdetails bekijken
git log --oneline -3
git show HEAD

# Alle wijzigingen klaarzetten en in één stap committen
git commit -a -m "Update dependencies to latest versions"

Commits vormen een gerichte acyclische graaf (DAG), waarbij elke nieuwe commit naar de vorige verwijst. Dit maakt navigatie door de geschiedenis, het terugdraaien van wijzigingen en analyse van de codebase-evolutie mogelijk. Begrip van de Git DAG-structuur — de basis voor geavanceerd werk met commits.

Hoe wijzigingen correct committen

Het commitproces in Git bestaat uit twee fasen: het toevoegen van wijzigingen aan de staging area (index) en het aanmaken van de commit. De staging area stelt de ontwikkelaar in staat te selecteren welke wijzigingen in de commit worden opgenomen, zelfs als er veel bestanden zijn gewijzigd in de werkdirectory.

De atomiciteitsregel — het kernprincipe van een goede commit. Elke commit moet één logische wijziging bevatten. Als een ontwikkelaar een bug repareert en code refactort — zijn dit twee verschillende commits. Atomaire commits vereenvoudigen code-review, het terugdraaien van wijzigingen en geschiedenisanalyse.

Voor het committen is het goed te controleren: of er debug-uitvoer, uitgecommentarieerde blokken of toevallige wijzigingen in de code zijn achtergebleven. Hiervoor wordt het commando git diff --cached gebruikt, dat toont wat er precies in de commit komt. Extra controle via git status geeft de lijst van bestanden in de staging area.

• Controleer wijzigingen — git diff --cached toont wat er in de commit komt
• Controleer kwaliteit — code moet vóór commit door linter en tests komen
• Schrijf bericht — begrijpelijke beschrijving van het wijzigingsdoel
• Controleer staged — git status bevestigt de bestandslijst

Regels voor het schrijven van commitberichten

Het commitbericht is de documentatie van de wijziging voor toekomstige ontwikkelaars. Een goed bericht beantwoordt de vragen: wat is gewijzigd en waarom. De Conventional Commits-conventie (Angular team, 2016) is de standaard geworden voor veel projecten en definieert het formaat: type(gebied): beschrijving.

Een goed commitbericht bestaat uit een kop (tot 50 tekens) en een body (optioneel, tot 72 tekens per regel). De kop wordt in de gebiedende wijs geschreven: „Add” niet „Added” of „Adds”. Hoofdletter en punt aan het einde van de kop worden niet gebruikt — dit is de internationale Git-conventie.

Slecht bericht: „fix things” of „update” — bevat geen informatie. Over een maand kan de ontwikkelaar niet begrijpen wat er precies is gewijzigd en waarom. Goed bericht: „fix(payment): handle timeout in stripe callback” — meteen duidelijk waar en wat is gerepareerd.

Veelgemaakte fouten bij commits

Ontwikkelaars, vooral beginners, maken vaak typische fouten bij commits. De meest voorkomende — te grote commit waarin tientallen wijzigingen zijn vermengd. Zo'n commit kan niet gedeeltelijk worden teruggedraaid en code-review wordt een marteling.

De tweede meest voorkomende fout — een slecht commitbericht. Berichten van het type „fix”, „update”, „changes” of „wip” geven geen context aan toekomstige ontwikkelaars. Over een half jaar weet niemand meer wat er precies is gerepareerd. De regel is simpel: stel je voor dat je over een jaar in de geschiedenis kijkt en een specifieke wijziging probeert te vinden.

De derde fout — commit van niet-gecompileerde of niet-werkende code. Na een commit moet code ten minste compileren. Niet-gestripte build — de basisvereiste voor elke commit in een gedeelde branch. Hiervoor worden voor de commit de build en tests uitgevoerd.

De vierde fout — commit met vertrouwelijke gegevens. API-sleutels, wachtwoorden en tokens mogen niet in de Git-geschiedenis terechtkomen. Als een geheim al is gecommit, is het niet voldoende om het in een nieuwe commit te verwijderen — het moet uit de hele geschiedenis worden verwijderd via git filter-branch of BFG Repo-Cleaner.

Geavanceerde technieken voor werken met commits

Git biedt hulpmiddelen voor het beheren van de commitgeschiedenis. Een van de nuttigste is git commit --amend, waarmee de laatste commit kan worden aangevuld met nieuwe wijzigingen of het bericht kan worden gecorrigeerd. Dit is handig als de ontwikkelaar vergeten is een bestand toe te voegen of een fout in het bericht heeft gemaakt.

# Laatste commitbericht corrigeren
git commit --amend -m "fix(auth): correct token validation logic"

# Vergeten bestand toevoegen aan laatste commit
git add missed-file.txt
git commit --amend --no-edit

# Interactieve rebase voor laatste 3 commits
git rebase -i HEAD~3

Interactive rebase — een krachtig hulpmiddel voor het herschrijven van geschiedenis. Maakt het mogelijk commits samen te voegen (squash), berichten te wijzigen (reword), de volgorde te veranderen (reorder) en commits te verwijderen (drop). Rebase wijzigt echter de geschiedenis, dus wordt het alleen toegepast op lokale commits die nog niet naar de externe repository zijn gepusht.

Voor het terugdraaien van commits bestaan twee benaderingen. git revert maakt een nieuwe commit aan die de wijzigingen van de vorige ongedaan maakt — een veilige methode die de geschiedenis behoudt. git reset verwijdert commits uit de geschiedenis — gevaarlijk als commits al zijn gepusht. In teamontwikkeling wordt alleen git revert gebruikt voor het terugdraaien van gepubliceerde commits.