7.1 Git Tools - Revisie Selectie

Je kunt uiteraard refereren aan een commit met de SHA-1 hash die eraan is gegeven, maar er zijn ook meer mens-vriendelijke manieren om aan commits te referen. Deze paragraaf toont de verschillende manieren waarmee je kunt refereren aan een enkele commit.

Git is slim genoeg om uit te knobbelen welke commit je wilde typen als je de eerste paar karakters geeft, zolang als je verkorte SHA-1 op z’n minst 4 karakters lang is en eenduidig; dus, slechts één object in de huidige repository begint met dat deel-SHA-1.

Bijvoorbeeld, om een specifieke commit te zien, stel dat je een git log commando gebruikt en de commit waar je een bepaalde functie hebt toegevoegd identificeert:

Stel dat we geinteresseerd zijn in de commit waarvan de hash begint met 1c002dd..... Je kunt deze commit bekijken met elk van de volgend variaties van het git show commando (aangenomen dat de kortere versies uniek zijn):

Git kan met een korte, unieke afkorting van je SHA-1 waarden overweg. Als je --abbrev-commit doorgeeft aan het git log commando, zal de uitvoer de korte waarden gebruiken, maar ze uniek houden; het gebruikt standaard zeven karakters, maar zal ze langer maken als dat nodig is om de SHA-1 eenduidig te houden:

Over het algemeen zijn acht tot tien karakters meer dan genoeg om binnen een project uniek te zijn. Om een voorbeeld te geven: per februari 2019 bevat de Linux kernal (wat een redelijk groot project is) meer dan 875.000 commits en bijna zeven miljoen objecten in de object database, waarin geen twee objecten waavan de SHA-1s in de eerste 12 karakters gelijk zijn.

Een directe manier om naar een specifieke commit te verwijzen is als het de commit is aan de punt van een branch; in dat geval kan je de branchnaam in elke Git commando gebruiken die een referentie naar een commit verwacht. Bijvoorveeld, als je het laatste commit object op een branch wilt laten zien, zijn de volgende commando’s gelijk, aangenomen dat de topic1-branch wijst naar ca82a6d:

Als je wilt zien naar welke specifieke SHA-1 een branch wijst, of als je wilt zien waar elk van deze voorbeelden op neerkomt in termen van SHA-1s, kan je het Git binnenwerk instrument (plumbing tool) geheten rev-parse gebruiken. Je kunt Git Binnenwerk bekijken voor meer informatie over plumbing tools; het komt erop neer dat rev-parse er is voor onder-water operaties en dat het niet bedoeld is voor het dagelijks gebruik. Dit gezegd hebbende, het kan soms handig zijn als het nodig is om te zien wat er echt gebeurt. Hier kan je rev-parse op je branch laten lopen.

Een van de dingen die Git op de achtergrond doet als je aan het werk bent is een “reflog” bijhouden — een logboek waarin wordt bijgehouden waar je HEAD en branch referenties in de afgelopen paar maanden zijn geweest.

Je kunt de reflog zien door git reflog te gebruiken:

Elke keer als de punt van je branch voor welke reden dan ook wordt bijgewerkt, slaat Git die informatie voor je op in deze tijdelijke historie. En je kunt ook aan oudere commits refereren met deze gegevens. Als je bijvoorbeeld de vijfde vorige waarde van de HEAD van je repository wilt zien, kan je de @{5} referentie gebruiken die je in de reflog uitvoer ziet:

Je kunt deze syntax ook gebruiken om te zien waar een branch was op een specifieke moment in het verleden. Als je bijvoorbeeld wilt zien waar je master-branch gister was, kan je dit typen

Dat toont je waar de punt van de master-branch gister was. Deze techniek werkt alleen voor gegevens die nog steeds in je reflog staan, dus je kunt het niet gebruiken om commits op te zoeken die ouder dan een paar maanden zijn.

Om de reflog informatie geformatteerd te tonen zoals de git log uitvoer, kan je git log -g uitvoeren:

Het is belangrijk op te merken dat de reflog informatie puur lokaal is — het is een log van wat jij gedaan hebt in jouw repository. De referentie zal niet hetzelfde zijn op de kopie van een ander van de repository, en direct nadat je initieel een kloon van een repository gemaakt hebt zal je een lege reflog hebben, omdat er nog geen activiteiten hebben plaatsgevonden op jouw repository. Het uitvoeren van git show HEAD@{2.months.ago} zal alleen werken als je het project op z’n minst 2 maanden geleden hebt gekloond — als je het recentelijker geleden hebt gekloond zal je alleen je eerste lokale commit zien.

De andere veelgebruikte manier om een commit te specificeren is via zijn voorouders. Als je een ^ (caret) aan het eind van een referentie plaatst, zal Git dit interpreteren als een referentie aan de ouder van deze commit. Stel dat je naar de historie van je project kijkt:

Dan kan je de vorige commit zien door HEAD^ te specificeren, wat “de ouder van HEAD” betekent:

Je kunt ook een getal aangeven na de ^ om aan te geven welke ouder je wilt; bijvoorbeeld: d921970^2 wat “de tweede ouder van d921970” betekent. Deze syntax is alleen nuttig voor merge commits, waar je meer dan een ouder hebt. De eerste ouderr van een merge commit is van de branch waar je op stond toen je mergede (meestal master), terwijl de tweede ouder van een merge commit van de branch is die werd gemerged (zeg, topic):

De andere belangrijke voorouder specificatie is de ~ (tilde). Deze refereert ook aan de eerste ouder, dus HEAD~ en HEAD^ zijn aan elkaar gelijk. Het verschil wordt duidelijk wanneer je een getal specificeert. HEAD~2 betekent “de eerste ouder van de eerste ouder”, of “de grootouder” — het loopt het aantal keren terug over de eerste ouders dat je specificeert. Even weer als voorbeeld, in de historie van hiervoor, HEAD~3 zou dit opleveren:

Dit kan ook als HEAD~~~ worden geschreven, wat wederom de eerste ouder van de eerste ouder van de eerste ouder aanduidt:

Je kunt deze syntaxen ook combineren; je kunt de tweede ouder van de vorige referentie krijgen (aangenomen dat het een merge commit was) door HEAD~3^2 te gebruiken, en zo voort.

Nu dat je individuele commits kunt aanwijzen, laten we eens kijken hoe je een reeks van commits kunt aanduiden. Dit is in het bijzonder nuttig voor het beheren van je branches — als je veel branches hebt, kan je reeks-specificaties gebruiken om vragen te beantwoorden als “Welk werk zit op deze branch die ik nog niet gemerged heb in mijn hoofdbranch?”.