Git Blame uitgelegd: zo spoor je codegeschiedenis op en werk je slimmer samen

Git is een krachtig hulpmiddel om codewijzigingen bij te houden. Het helpt teams wijzigingen te volgen, efficiënt samen te werken en problemen te debuggen. Het biedt verschillende tools om codegeschiedenis te beheren; een van de nuttigste is git blame. Met dit commando kun je de herkomst van elke regel in een bestand traceren en zien wie hem het laatst heeft aangepast en wanneer.

In dit artikel verkennen we hoe je git blame gebruikt om wijzigingen in een project te volgen. We beginnen met basiscommando's en gaan stap voor stap naar geavanceerde functies, zoals specifieke revisies negeren, integratie met ontwikkeltools en het toepassen van best practices. Aan het einde heb je een goed begrip van hoe je codegeschiedenis effectief analyseert en de samenwerking binnen je team verbetert.

Wat is Git Blame?

Codewijzigingen kunnen lastig te volgen zijn, zeker in grote projecten met meerdere bijdragers. Inzicht in de geschiedenis van een bestand is cruciaal voor debuggen, het beoordelen van eerdere beslissingen en het waarborgen van codekwaliteit. Zonder duidelijke geschiedenis kan het voor teams moeilijk zijn om te achterhalen waarom een bepaalde wijziging is doorgevoerd of wie je om verduidelijking moet vragen.

Daarom is git blame zo waardevol. Het laat je wijzigingen tot op regelniveau aanwijzen, en toont commitdetails naast elke regel code. Met deze informatie vind je snel de relevante commit, bekijk je het bijbehorende bericht en zie je de bredere context van de wijziging. Of je nu een bug aan het oplossen bent, aanpassingen beoordeelt of simpelweg de evolutie van een bestand wilt begrijpen, git blame biedt de inzichten die je nodig hebt om onderbouwde beslissingen te nemen.

Waarom git blame gebruiken?

Als je in een team werkt of een probleem debugt, kan het handig zijn om te weten wie een regel code het laatst heeft bewerkt. Als een bug verschijnt na een recente update, helpt git blame de exacte wijziging te vinden die het probleem introduceerde. Het stelt developers ook in staat de juiste persoon te benaderen wanneer ze verduidelijking nodig hebben over een specifiek issue.

Dit commando is ook nuttig om de achterliggende reden van wijzigingen te begrijpen. Codecommentaar en commitberichten vatten soms niet het volledige denkproces. Door een wijziging terug te leiden naar een specifieke commit, kunnen developers gerelateerde discussies bekijken en het grotere plaatje zien.

Meer leren? Bekijk onze Git- en GitHub-tutorial, een gids voor beginners die uitlegt hoe versiebeheer met Git werkt en waarom het zo belangrijk is in data science-projecten.

Basisgebruik van git blame

De basis-syntax van git blame is:

git blame <file>

Dit commando annoteert elke regel met de laatste commit die deze heeft aangepast, inclusief auteur, tijdstempel en commit-hash. Hier is een voorbeeld:

$ git blame example.py
derrickmwiti@Derricks-MacBook-Pro remixer % git blame src/components/ContentGenerator.vue
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    1) <template>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    2)   <div class="content-generator">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    3)     <div class="card h-100 border-0 shadow-sm">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    4)       <div class="card-header bg-white border-bottom-0 pt-4">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    5)         <div class="d-flex justify-content-between align-items-center mb-3">
289030a0 (Derrick Mwiti 2025-03-11 12:47:11 +0300    6)           <div class="d-flex align-items-center gap-2">
289030a0 (Derrick Mwiti 2025-03-11 12:47:11 +0300    7)             <h5 class="mb-0">Content Generator</h5>
289030a0 (Derrick Mwiti 2025-03-11 12:47:11 +0300    8)             <span class="badge bg-secondary" v-if="openaiModel">{{ openaiModel }}</span>
289030a0 (Derrick Mwiti 2025-03-11 12:47:11 +0300    9)           </div>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   10)         </div>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   11) 
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   12) 
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   13)         <nav>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   14)           <div class="nav nav-tabs card-header-tabs gap-1" id="nav-tab" role="tablist">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   15)             <button
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   16)               v-for="platform in platforms"
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   17)               :key="platform"
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300   18)               class="nav-link"

Elke regel bevat:

• De commit-hash (^3b1aef2 en ^8f2c4d3)
• De naam van de auteur (Derrick Mwiti)
• Het tijdstip van de laatste wijziging
• De daadwerkelijke regel code

Praktische toepassingen van Git Blame

Nu je de basis-syntax van git blame kent, kijken we hoe je dit in alledaagse ontwikkelsituaties toepast.

De auteur van een specifieke regel vinden

Als een bestand groot is en je slechts een bepaald deel wilt inspecteren, geef dan een regelbereik op:

derrickmwiti@Derricks-MacBook-Pro remixer % git blame -L 10,20  src/components/ContentGenerator.vue
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 10)         </div>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 11) 
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 12) 
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 13)         <nav>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 14)           <div class="nav nav-tabs card-header-tabs gap-1" id="nav-tab" role="tablist">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 15)             <button
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 16)               v-for="platform in platforms"
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 17)               :key="platform"
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 18)               class="nav-link"
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 19)               :class="{ active: activeTab === platform }"
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300 20)               :id="nav-${platform}-tab"

Dit richt zich op regels 10 tot en met 20, zodat je relevante wijzigingen makkelijker vindt.

Wijzigingen begrijpen met git show

Hoewel git blame de laatste wijziging per regel laat zien, vertelt het niet wat er in die commit is aangepast. Voor meer details gebruik je git show <commit-hash>:

derrickmwiti@Derricks-MacBook-Pro remixer % git show  28203e0
commit 28203e0f7cbe92c6baf6897a54686e87d16c9cda
Author: Derrick Mwiti <mwitiderrick@gmail.com>
Date:   Mon Mar 10 17:48:31 2025 +0300


diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 0000000..5a5809d
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,9 @@
+[*.{js,jsx,mjs,cjs,ts,tsx,mts,cts,vue,css,scss,sass,less,styl}]
+charset = utf-8
+indent_size = 2
+indent_style = space
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+end_of_line = lf
+max_line_length = 100
diff --git a/.env b/.env
:

Door <commit-hash> te vervangen door de daadwerkelijke commit-ID uit git blame krijg je het volledige commitbericht en de code-diff te zien, wat helpt om de reden achter de wijziging te begrijpen.

Wil je verder de diepte in? Bekijk onze Git Diff-tutorial en leer hoe je git diff effectief gebruikt, van basisvergelijkingen tot geavanceerde technieken.

Geavanceerde functies van Git Blame

Hier zijn enkele uitgebreidere manieren waarop je Git blame in je workflow kunt inzetten: 

Whitespace-wijzigingen negeren

Sommige opmaakwijzigingen, zoals inspringing corrigeren, hebben geen invloed op de logica. Om deze eruit te filteren, gebruik je git blame -w <file>:

derrickmwiti@Derricks-MacBook-Pro remixer % git blame -w src/components/ContentGenerator.vue       
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    1) <template>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    2)   <div class="content-generator">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    3)     <div class="card h-100 border-0 shadow-sm">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    4)       <div class="card-header bg-white border-bottom-0

Specifieke revisies negeren

Als bepaalde commits (zoals bulk-herformattering) de blame-geschiedenis vervuilen, kun je ze negeren met git blame --ignore-rev <commit-hash> <file>:

derrickmwiti@Derricks-MacBook-Pro remixer % git blame --ignore-rev 28203e0 src/components/ContentGenerator.vue 
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    1) <template>
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    2)   <div class="content-generator">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    3)     <div class="card h-100 border-0 shadow-sm">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    4)       <div class="card-header bg-white border-bottom-0 pt-4">
^28203e0 (Derrick Mwiti 2025-03-10 17:48:31 +0300    5)         <div class="d-flex justify-content-between align-items-center mb-3">
289030a0 (Derrick Mwiti 2025-03-11 12:47:11 +0300    6)           <div class="d-flex align-items-center gap-2">

Om meerdere commits consequent te negeren, kun je ze in een bestand opnemen en dit verwijzen met de optie --ignore-revs-file. Zo houd je de blame-geschiedenis schoon door irrelevante wijzigingen uit te sluiten.

Maak in de hoofdmap van je repository een bestand met de naam .git-blame-ignore-revs. Zet de commit-hashes die je wilt negeren onder elkaar, eventueel met opmerkingen voor duidelijkheid:

# Commit die codeformattering introduceert
a926bba49c89a5b882cd298be3af2570b1e6252c

Voer het volgende commando uit om de opgegeven revisies te negeren:​

git blame --ignore-revs-file .git-blame-ignore-revs filename

Voer het volgende commando uit om Git standaard jouw ignore-bestand te laten gebruiken:

git config blame.ignoreRevsFile .git-blame-ignore-revs

E-mailadressen van auteurs tonen in plaats van namen

Om het e-mailadres van de auteur te tonen in plaats van de naam:

derrickmwiti@Derricks-MacBook-Pro remixer % git blame --show-email  src/components/PostsManager.vue
dbe547ec (<derrick@gmail.com> 2025-03-11 09:22:59 +0300   1) <template>
dbe547ec (<derrick@gmail.com> 2025-03-11 09:22:59 +0300   2)   <div class="posts-manager">
dbe547ec (<derrick@gmail.com> 2025-03-11 09:22:59 +0300   3)     <h3>Saved Posts</h3>
dbe547ec (<derrick@gmail.com> 2025-03-11 09:22:59 +0300   4)     
dbe547ec (<derrick@gmail.com> 2025-03-11 09:22:59 +0300   5)     <div v-if="loading" class="text-center my-4">
dbe547ec (<derrick@gmail.com> 2025-03-11 09:22:59 +0300   6)       <div class="spinner-border text-primary" role="status">

Dit kan handig zijn om contact op te nemen met de persoon die verantwoordelijk is voor een specifieke wijziging.

Volledige commit-hashes weergeven

Standaard toont git blame verkorte commit-hashes. Om de volledige hashes te zien, voer je uit:

derrickmwiti@Derricks-MacBook-Pro remixer % git blame --abbrev=40 src/components/PostsManager.vue
dbe547ec4ece7cb2a1ff3dadb4770cc9ee9f161e (Derrick Mwiti 2025-03-11 09:22:59 +0300   1) <template>
dbe547ec4ece7cb2a1ff3dadb4770cc9ee9f161e (Derrick Mwiti 2025-03-11 09:22:59 +0300   2)   <div class="posts-manager">
dbe547ec4ece7cb2a1ff3dadb4770cc9ee9f161e (Derrick Mwiti 2025-03-11 09:22:59 +0300   3)     <h3>Saved Posts</h3>
dbe547ec4ece7cb2a1ff3dadb4770cc9ee9f161e (Derrick Mwiti 2025-03-11 09:22:59 +0300   4)     
be547ec4ece7cb2a1ff3dadb4770cc9ee9f161e (Derrick Mwiti 2025-03-11 09:22:59 +0300   5)     <div v-if="loading" class="text-center my-4">

Je kunt de lengte van de abbreviaties in Git blame aanpassen met de optie --abbrev=<n>.

git blame gebruiken in Visual Studio Code

Voor developers die Visual Studio Code gebruiken, biedt de Git Blame-extensie ingebouwde ondersteuning voor git blame. 

Met deze extensie kun je:

• Inline blame-annotaties bekijken.
• Over regels hoveren om commitdetails te zien.
• Volledige bestands- en regelgeschiedenis openen.

Best practices voor Git Blame

Een .git-blame-ignore-revs-bestand onderhouden zorgt ervoor dat formatteringscommits de blame-geschiedenis niet vervuilen. In teamverband helpt het als iedereen dezelfde conventies volgt voor het negeren van revisies.

Bij het gebruik van git blame is het doel altijd om de reden achter wijzigingen te begrijpen, niet om met de vinger te wijzen. Het is een tool om te leren en de samenwerking te verbeteren, zodat developers efficiënter samen kunnen werken.

Conclusie 

In dit artikel hebben we behandeld hoe git blame developers helpt om wijzigingen in hun code te volgen. Van basisgebruik tot geavanceerde functies: we hebben gezien hoe dit commando duidelijkheid biedt over wie een bestand heeft aangepast en wanneer.

Je kunt dit commando optimaliseren door het te integreren met andere Git-tools, zoals git show, en door genegeerde revisies te configureren. Of je nu een probleem debugt, wijzigingen beoordeelt of simpelweg de geschiedenis van een bestand wilt begrijpen, git blame biedt waardevolle inzichten die het onderhoud van code en samenwerking verbeteren.

Het beheersen van tools zoals git blame helpt je om met vertrouwen door codebases te navigeren, effectiever samen te werken en schonere projectgeschiedenissen te onderhouden. Het gaat niet alleen om achterhalen wie een regel heeft aangepast, maar vooral waarom—en die inzichten benutten om betere software te bouwen. Wil je dieper duiken in het Git-ecosysteem? Bekijk dan onze uitgebreide Git-cursus of ga aan de slag met onze Git-cursus voor gevorderde beginners.