Uitgebreid Git log

Dit laat je weten dat de bovenste commit ook is uitgecheckt (aangeduid met HEAD) en dat het ook het tip van de main-branch is. De tweede commit heeft een andere branch die ernaar verwijst, genaamd feature, en tot slot is de 4e commit getagd als v0.9.

Branches, tags, HEAD en de commit-geschiedenis zijn bijna alle informatie in je Git-repository, dus dit geeft je een vollediger beeld van de logische structuur van je repository.

De opdracht git log bevat veel opties om diff's weer te geven bij elke commit. Twee van de meest gebruikte opties zijn --stat en -p.

De optie --stat geeft het aantal invoegingen en verwijderingen weer in elk bestand dat door elke commit is gewijzigd (merk op dat het wijzigen van een regel wordt voorgesteld als 1 invoeging en 1 verwijdering). Dit is handig als je een korte samenvatting wilt van de wijzigingen die door elke commit zijn geïntroduceerd. De volgende commit heeft bijvoorbeeld 67 regels aan het bestand hello.py toegevoegd en 38 regels verwijderd:

Het aantal tekens + en - naast de bestandsnaam geeft het relatieve aantal wijzigingen aan in elk bestand dat door de commit is gewijzigd. Dit geeft je een idee waar de wijzigingen voor elke commit te vinden zijn.

Als je de daadwerkelijke wijzigingen wilt zien die door elke commit zijn geïntroduceerd, kun je de -p optie aan git log toevoegen. Dit geeft de volledige patch weer die die commit vertegenwoordigt:

De opdracht git shortlog is een speciale versie van git log, bedoeld voor het maken van releaseaankondigingen. Elke commit wordt gegroepeerd op auteur en de eerste regel van elk commit-bericht wordt weergegeven. Dit is een makkelijke manier om te zien wie aan wat heeft gewerkt.

Als twee ontwikkelaars bijvoorbeeld 5 commits aan een project hebben bijgedragen, kan de output van git shortlog er als volgt uitzien:

Git shortlog sorteert de output standaard op auteursnaam, maar je kunt ook de optie -n gebruiken om te sorteren op het aantal commits per auteur.

De optie --graph tekent een ASCII-grafiek die de branchestructuur van de commit-geschiedenis weergeeft. Dit wordt vaak gebruikt in combinatie met de opdrachten --oneline en --decorate om gemakkelijker te kunnen zien welke commit bij welke branch hoort:

Voor een eenvoudige repository met slechts 2 branches levert dit het volgende op:

Het sterretje geeft aan in welke branch de commit was. De bovenstaande grafiek laat ons dus zien dat de commits 23ad9ad en 16b36c6 betrekking hebben op een topic-branch en de rest op de main-branch.

Hoewel dit een leuke optie is voor eenvoudige repository's, ben je waarschijnlijk beter af met een volledigere visualisatietool zoals gitk of Sourcetree voor projecten met veel branches.

Voor al je andere behoeften op het gebied van de opmaak van git log kun je de optie --pretty=format:"" gebruiken. Zo kun je elke commit weergeven zoals je wilt, met behulp van tijdelijke aanduidingen in printf stijl.

De tekens %cn, %h en %cd in de volgende opdracht worden bijvoorbeeld vervangen door respectievelijk de naam van de committer, de afgekorte commithash en de datum van de committer.

Dit resulteert in de volgende opmaak voor elke commit:

De volledige lijst met tijdelijke aanduidingen is te vinden in het gedeelte Pretty Formats op de pagina git Llog van de handleiding.

Behalve dat je alleen de informatie kunt weergeven waarin je geïnteresseerd bent, is de optie --pretty=format:"" vooral handig als je de output van git log met een pipe probeert door te geven naar een andere opdracht.

De opmaak van de manier waarop elke commit wordt weergegeven, is slechts de helft van de opgave om git log te leren. De andere helft is begrijpen hoe je door de commit-geschiedenis moet navigeren. In de rest van dit artikel worden enkele geavanceerde manieren beschreven om specifieke commits uit je projectgeschiedenis te selecteren met behulp van git log. Deze kunnen allemaal worden gecombineerd met elk van de hierboven besproken opmaakopties.

Als je op zoek bent naar een commit voor een bepaald tijdsbestek, kun je de vlaggen --after of --before gebruiken om commits op datum te filteren. Beide accepteren verschillende datumnotaties als parameter. De volgende opdracht toont bijvoorbeeld alleen commits die zijn aangemaakt na 1 juli 2014 (inclusief):

Je kunt ook relatieve referenties invoeren, zoals "1 week ago" en "yesterday":

Om te zoeken naar commits die zijn gemaakt tussen twee datums, kun je zowel een --before als --after datum opgeven. Om bijvoorbeeld alle commits weer te geven die zijn toegevoegd tussen 1 juli 2014 en 4 juli 2014, zou je het volgende gebruiken:

Als je alleen op zoek bent naar commits die door een bepaalde gebruiker zijn gemaakt, gebruik dan de vlag --author. Dit accepteert een reguliere expressie en retourneert alle commits waarvan de auteur met dat patroon overeenkomt. Als je precies weet naar wie je op zoek bent, kun je een gewone tekenreeks gebruiken in plaats van een reguliere expressie:

Hiermee worden alle commits weergegeven waarvan de auteursnaam John bevat. De naam van de auteur hoeft niet exact overeen te komen, maar moet alleen de gespecificeerde zin bevatten.

Je kunt ook reguliere expressies gebruiken om complexere zoekopdrachten uit te voeren. Met de volgende opdracht wordt bijvoorbeeld gezocht naar commits van Mary of John.

Let op: het e-mailadres van de auteur staat ook bij de naam van de auteur. Je kunt deze optie dus ook gebruiken om op e-mail te zoeken.

Als in je workflow een onderscheid wordt gemaakt tussen committers en auteurs, dan werkt de vlag van --committer op dezelfde manier.

Gebruik de vlag --grep om commits te filteren op basis van hun commit-bericht. Dit werkt precies zoals de hiervoor besproken vlag --author, maar matcht tegen het commit-bericht in plaats van de auteur.

Als je team bijvoorbeeld relevante issuenummers opneemt in elk commit-bericht, kun je zoiets als het volgende gebruiken om alle commits met betrekking tot dat issue te pullen:

Je kunt de parameter -i ook doorgeven aan git log om ervoor te zorgen dat verschillen tussen hoofdletters en kleine letters worden genegeerd tijdens het matchen van patronen.

Vaak ben je alleen geïnteresseerd in wijzigingen die in een bepaald bestand zijn aangebracht. Om de geschiedenis van een bestand weer te geven, hoef je alleen maar het bestandspad door te geven. Het volgende retourneert bijvoorbeeld alle commits die betrekking hadden op het bestand foo.py of bar.py:

De parameter -- wordt gebruikt om bij git log aan te geven dat de volgende argumenten bestandspaden zijn en niet branchnamen. Als er geen kans op verwarring met een branch bestaat, kun je -- weglaten.

Het is ook mogelijk te zoeken naar commits die een bepaalde regel broncode invoeren of verwijderen. Dit wordt een pickaxe genoemd en heeft de vorm -S-"". Als je bijvoorbeeld wilt weten wanneer de string Hello, World! is toegevoegd aan een bestand in het project, zou je de volgende opdracht kunnen gebruiken:

Als je wilt zoeken met een reguliere expressie in plaats van met een string, kun je in plaats daarvan de vlag -G"" gebruiken.

Dit is een zeer krachtige tool voor foutopsporing, omdat je hiermee alle commits kunt vinden die betrekking hebben op een bepaalde regel code. Het kan je zelfs laten zien wanneer een regel is gekopieerd of verplaatst naar een ander bestand.

Je kunt een bereik aan commits aan git log doorgeven om alleen de commits in dat bereik weer te geven. Het bereik wordt gespecificeerd in de volgende indeling, waarbij en commitreferenties zijn:

Deze opdracht is vooral handig als je branchingreferenties gebruikt als parameter. Het is een eenvoudige manier om de verschillen tussen twee branches te laten zien. Bekijk de volgende opdracht:

Het bereik main..feature bevat alle commits die in de feature-branch staan, maar niet in de main-branch. Met andere woorden, dit is hoe ver deze feature is gevorderd sinds ze is afgetakt van de main. Je kunt dit als volgt visualiseren:

Let op: als je de volgorde van het bereik wijzigt (feature..main), krijg je in main alle commits, maar niet in feature. Als git log voor beide versies commits uitvoert, dan betekent dit dat je geschiedenis uiteegelopen is.

Git log bevat standaard commits voor samenvoegen in de uitvoer. Maar als je team een beleid hanteert dat altijd samenvoegt (dat wil zeggen dat je upstream-wijzigingen samenvoegt in topic-branches in plaats van de topic-branch te rebaseren naar de upstream-branch), dan heb je veel externe commits voor samenvoeging in je projectgeschiedenis.

Je kunt voorkomen dat git log deze samenvoegingscommits weergeeft door de vlag --no-merges toe te voegen:

Aan de andere kant, als je alleen geïnteresseerd bent in de samenvoegcommits, kun je de vlag --merges gebruiken:

Dit is het resultaat van alle commits die minstens twee bovenliggende elementen hebben.

Je zou het nu vrij gemakkelijk moeten vinden om de geavanceerde parameters van git log te gebruiken om de uitvoer op te maken en te selecteren welke commits je wilt weergeven. Dit geeft je de mogelijkheid om precies uit je projectgeschiedenis te pullen wat je nodig hebt.

Deze nieuwe vaardigheden vormen een belangrijk onderdeel van je Git-toolkit, maar vergeet niet dat git log vaak wordt gebruikt in combinatie met andere Git-opdrachten. Als je eenmaal de commit hebt gevonden die je zoekt, geef je die meestal door aan git checkout, git revert of een andere tool om je commitgeschiedenis te manipuleren. Zorg er dus voor dat je op de hoogte blijft van de geavanceerde functies van Git.