Git voor gevorderden: Krachtige commando’s die verder gaan dan de basis

Git is een krachtig programma voor versiebeheer en heeft een soort monopolie op dit gebied. Voor de meeste dagelijkse taken is Git eenvoudig te gebruiken dankzij de herhaling van commando’s. Er zijn echter veel situaties waarin je meer nodig hebt dan de basis. Daarom willen we het hebben over geavanceerde Git commando’s die jouw Git vaardigheden naar een hoger niveau kunnen tillen.

Daarnaast zullen we je ook kennis laten maken met verschillende Git concepten die je normaal gesproken niet tegenkomt. Denk hierbij aan het opslaan van wijzigingen in plaats van committen, rebasen en bestanden toevoegen aan je testomgeving. Met deze kennis op zak, zul je merken dat je nog waardevoller bent voor je team.

In deze blogpost introduceren we verschillende krachtige commando’s die je wilt kennen. Om deze te kunnen gebruiken, moet je echter over een aantal vaardigheden, concepten en informatie beschikken. Laten we hier eerst eens naar kijken.

Aanbevolen vereisten

Hoewel je misschien in staat bent om in een paar dagen de basis van Git op te pikken en de meest populaire commando’s onder de knie te krijgen, zoals git delete, is meer ervaring nodig om geavanceerde commando’s te kunnen gebruiken.

De tips die we hier delen zullen niet geschikt zijn voor een beginner met Git, dus als versiebeheer in het algemeen nieuw voor je is, raden we je aan wat tijd te besteden aan het dagelijks gebruiken van de basiscommando’s voordat je meer aan je repertoire gaat toevoegen.

In het kort is hier een korte lijst van aspecten die je nu al wil begrijpen:

• Kernbegrippen van Git zoals commits, branches, pull requests en meer.
• Bekendheid met Git basiscommando’s zoals git add, git merge, git commit, en git push.
• Voor geavanceerde Git taken moet je door een Terminal kunnen navigeren.

Het is handig om ervaring te hebben met het werken met Git in een teamomgeving, omdat veel van deze commando’s een grote impact kunnen hebben op een gedeelde codebase. Het kan bijvoorbeeld zijn dat je sommige van deze commando’s alleen gebruikt in een verantwoordelijke positie. Dit betekent dat je voorzichtig moet zijn en moet begrijpen wanneer je deze commando’s gebruikt.

Git voor gevorderden: 12 krachtige commando’s die je wil weten

De rest van dit artikel zal 12 verschillende geavanceerde Git commando’s behandelen die je verder zullen brengen dan de basis en je hopelijk in een Git wizard zullen veranderen. Laten we beginnen met één commando dat je misschien meer gebruikt dan andere.

1. Rebasen

Rebase is een krachtig Git commando dat een alternatief is voor een pull request. Het laat je alle nieuwe commits die je maakt na een branch divergentie in een nieuwe branch pullen en de wijzigingen in de top van de basis plaatsen. Dit zal handig zijn als je wijzigingen van een andere branch wilt opnemen zonder een samenvoeg commit te maken om wat voor reden dan ook.

Een veel voorkomende toepassing voor rebasen is als je aan een feature branch werkt, en je wijzigingen van de hoofd branch wilt opnemen zonder een merge commit aan te maken. Het helpt om de geschiedenis van je project schoon te houden, hoewel het langer kan duren om uit te voeren, en je meer fouten kunt zien tijdens een samenvoeging.

Om een branch te rebasen, gebruik je het git rebase commando. Hier is een voorbeeld waarbij we een branch rebasen op een andere branch:

git checkout foo-branch

git rebase main

Je kunt ook een lijst maken van de commits die je gaat vrijgeven en je een kans geven om ze vooraf te bewerken. Zo kun je commits squashen, commit berichten bewerken en meer. Je kunt de --interactive of --i flag gebruiken om een ‘interactive rebase’ uit te voeren

git rebase --interactive <other-branch-name>

Daarover gesproken: commits mergen tot een enkele om de commitgeschiedenis op te ruimen is een veel voorkomende toepassing voor rebasen. Dit kan je commitgeschiedenis makkelijker te lezen en te begrijpen maken.

Om dit te doen tijdens een rebase, volg je de flag met het aantal commits dat je wilt squashen, wat de commits in één zal combineren:

git rebase -i HEAD~3

Dit zal een interactief rebasevenster openen, net als een commitvenster, waar je de commits die je wilt squashen kunt kiezen en bewerken:

Je hebt een lijst van commits aan de bovenkant van het scherm en een selectie van commando’s aan de onderkant, samen met wat andere relevante informatie. De standaard optie is om pick een commit te selecteren, wat het selecteert als degene die je wilt gebruiken zonder wijzigingen.

Er zijn echter genoeg andere commando’s om je te helpen bij het navigeren door een rebase. Je kunt bijvoorbeeld een commit herformuleren of meerdere commits samenvoegen. Om wijzigingen aan te brengen en de commando’s te gebruiken, werk je met de editor van je Terminal. De standaard is vaak Vim, wat betekent dat je die editor moet kennen.

De laatste stap is om je wijzigingen op te slaan en ze dan naar de remote branch te pushen.

2. Reverten, resetten en unstagen

Git is berucht als het gaat om het reverten van wijzigingen. Het is over het algemeen een lastig proces, met een neiging om fouten te veroorzaken. Maar als je wijzigingen in je werkmap of testgebied maakt die je ongedaan wilt maken, dan zijn er een paar Git commando’s die kunnen helpen.

Sterker nog, Git geeft je zelfs richtlijnen over hoe je een bestand ongedaan kunt maken als je een git status uitvoert:

Als zodanig kun je een commit van de huidige branch verwijderen en het met gemak ergens anders naartoe sturen:

git reset HEAD <commit>

Dit heeft het effect om je branch één commit terug te verplaatsen, alsof je de laatst bekende commit verwijdert. Je zou zelfs een gebruikssituatie kunnen hebben waarbij je een branch terug wilt zetten naar zijn oorspronkelijke state. Hier kun je resetten tegen de remote origin – bijvoorbeeld met git reset --hard origin/main. Merk echter op dat deze wijzigingen voor altijd weg zullen zijn.

Hoewel het git checkout commando er één is die je vaak zult gebruiken en als basis wordt beschouwd, kun je het ook gebruiken om bestanden te unstagen voor een commit:

git checkout -- <filename>

Let op de spatie tussen de streepjes en de bestandsnaam placeholder. Hier unstaget het commando het bestand dat je opgeeft en verwijdert de wijzigingen uit de werkmap. Merk op dat dit alle lokale wijzigingen die je in een bestand aanbrengt zal verwijderen. Dubbel- en driedubbelcheck dus of je die niet-opgeslagen wijzigingen niet nodig hebt.

Je kunt ook git revert gebruiken voor wijzigingen die je aanbrengt in een commit. Maar dit rolt de wijzigingen niet terug, maar creëert een nieuwe commit gebaseerd op het ongedaan maken van de wijzigingen in de vorige.

Het grote verschil hier is dat het commando geen referentiepunten naar de nieuwe commit zal verplaatsen, maar oude commits zal behouden. Dit is handig als je wijzigingen ongedaan wilt maken zonder ze uit je commitgeschiedenis te verwijderen.

Het commando verwacht een referentie te ontvangen, en het is eenvoudig om de laatste commit terug te draaien:

git revert HEAD

Maar je hebt veel meer mogelijkheden om bestanden en commits terug te zetten en te wijzigen. De volgende twee items op deze lijst van geavanceerde Git commando’s zullen daar naar kijken.

3. Bestanden terugzetten naar de standaard state

Met Git kun je eenvoudig een bestand terugzetten naar zijn standaard staat met een vrij nieuw commando: git restore. In feite zou je dit moeten beschouwen als een vervanging voor git reset in de meeste omstandigheden, omdat het veel krachtiger is. Je kunt bijvoorbeeld hetzelfde resultaat bereiken met git restore --staged <filename> als met git reset HEAD.

Het commando kan echter meer – je kunt ook bestanden terugzetten naar de standaardstate. Je kunt zien hoe je dit doet als je ook git status uitvoert:

git restore <filename>

Dit verwijdert de wijzigingen uit de werkmap alsof er niets is gebeurd. Net als met git checkout -- <filename> wil je er zeker van zijn dat je geen van de lokale wijzigingen wilt, want die zijn voor altijd weg.

4. Commits wijzigen

Er zullen waarschijnlijk veel momenten zijn waarop je een commit pusht en je dan realiseert dat je iets belangrijks vergeten bent toe te voegen. Met Git kun je eenvoudig de commit wijzigen om de ontbrekende wijzigingen toe te voegen.

Om dit te doen volg je een specifiek proces:

• Eerst breng je je wijzigingen aan in de bestanden die je nodig hebt voor het project.
• Stage ze zoals gebruikelijk met git add.
• Hercommit die wijzigingen in het testgebied met behulp van een ander commando om de commit te doen:

git commit --amend

Dit wijzigt de originele commit met de nieuwe en gebruikt daarvoor je testgebied. Zorg er dus voor dat je de oude versie van de commit niet nodig hebt, want die zal verloren gaan. We raden ook aan om de --amend flag te gebruiken met lokale commits in plaats van remote, om soortgelijke redenen als we elders in dit artikel behandelen.

Je kunt ook git commit --amend gebruiken om alleen het commit bericht te bewerken met het volgende commando:

git commit --amend -m "New commit message"

5. Git logging

Het gebruiken van Git’s log is waardevol om je te helpen de geschiedenis van een repository te begrijpen. Maar we zouden het git log commando niet als geavanceerd classificeren. In plaats daarvan kun je verschillende opties gebruiken om de uitvoer naar jouw wensen te filteren:

git log

git log --decorate

git log --stat

Bijvoorbeeld, het decoraten van een log-item print de ref namen af voor alle getoonde commits. De --stat optie toont invoegingen en verwijderingen voor een commit:

Je kunt ook andere opties gebruiken om de uitvoer van het log aan te passen – dit wordt ‘commit limiting’ genoemd Neem bijvoorbeeld de volgende commando’s:

git log --author=<author-name>

git log --grep=<pattern-string>

Hier kun je het logboek filteren op specifieke auteursnamen of tekstpatronen. Je kunt zelfs meerdere opties en flags combineren om een log te genereren voor een specifiek doel. Neem bijvoorbeeld deze opdracht:

git log --oneline --author=<author-name> --since=<date> feature-temp

Dit zoekt naar alle commits met de feature-temp branch van een enkele auteur sinds een gespecificeerde datum, en print het dan met enkele regel items. Merk op dat de parameter <date> ook een string kan zijn:

--since=”Two weeks ago”

Bovendien, als je een specifiek bestand wilt doorzoeken in plaats van een branch, kun je uitvoeren:

git log --oneline --author=bartonfink --since=”5 days ago” -- readme.rm

Deze set voorbeelden is slechts een tipje van de sluier van wat je met je logs kunt doen, maar er is genoeg ruimte om exacte commits te vinden op basis van je zoekcriteria.

6. Git hooks

Je gebruikt waarschijnlijk soms macro’s en andere geautomatiseerde scripts om code te helpen uitvoeren. Git bevat ook dit soort functionaliteit in de vorm van hooks. Deze scripts worden automatisch uitgevoerd als reactie op bepaalde gebeurtenissen, zoals commits of pushes. Er zijn ook veel manieren om hooks te gebruiken om code opmaak af te dwingen, tests uit te voeren en nog veel meer.

Er zijn twee soorten hooks: client-side en server-side:

• Client-site hooks worden geactiveerd op basis van lokale acties zoals commits en merges.
• Server-side hooks worden geactiveerd door netwerkoperaties. Dit kan zijn wanneer een repo een gepushte commit ontvangt, naast vele andere voorbeelden.

Git zal altijd je repo vullen met een aantal voorbeeldhooks als je een git init uitvoert. Je moet echter de .sample extensie verwijderen om ze te kunnen gebruiken:

Merk op dat je maar één type hook tegelijk kunt uitvoeren, hoewel het met wat werk mogelijk is om meerdere scripts tegelijk te gebruiken. Als zodanig moeten je bestandsnamen overeenkomen met het type hook dat je wilt gebruiken, gebaseerd op de voorbeeldscripts: pre-commit, update, enzovoort.

Een Git hook maken

Om een Git hook te maken, moet je een uitvoerbaar script maken in de .git/hooks submap zonder extensie. Het zal nog steeds draaien zolang je het toevoegt aan de hooks map.

Je kunt iedere scripttaal gebruiken die je wilt, zolang het maar als uitvoerbaar script kan draaien. Wij raden Ruby of Python aan, maar je kunt ook Bash, Perl en vele andere talen gebruiken. Het enige wat je hier hoeft te doen is het pad naar je interpreter veranderen ten opzichte van de standaard Bash:

#!/usr/bin/env python

Vanaf hier kun je je code normaal schrijven. Hier is bijvoorbeeld een prepare-commit script in Python dat de gebruiker vraagt om goede commitberichten te schrijven:

#!/usr/bin/env python

import sys, os

path_commit_msg = sys.argv[1]

with open(commit_msg_filepath, 'w') as f:

f.write("# You’ll need to provide a better commit message than that, buddy!")

Hoewel het niet altijd nodig is, raden we je aan om chmod +x .git/hooks/<hook-name> uit te voeren vanaf de command-line om er zeker van te zijn dat je het kunt uitvoeren.

Over het algemeen kunnen hooks een krachtige tool zijn voor het automatiseren van terugkerende taken en het afdwingen van best practices binnen je team.

7. Commit referrals

In Git identificeer je commits door de SHA-1 encryptie hash. Hoewel het mogelijk is om naar commits te referren via hun volledige hash, kan dit vervelend en foutgevoelig zijn:

bc7623b7a94ed3d8feaffaf7580df3eca4f5f5ca

In plaats daarvan biedt Git verschillende manieren om naar commits te referren met kortere, meer memorabele namen. Je kunt bijvoorbeeld een branch- of tagnaam gebruiken. Neem bijvoorbeeld een branch genaamd “develop”. Hier is een voorbeeld waarbij we verwijzen naar de laatste commit op deze branch:

git diff develop..HEAD

Dit laat de verschillen zien tussen de laatste commit (HEAD) op de “develop” branch en de huidige commit.

Je kunt ook naar een commit verwijzen door zijn relatieve positie binnen de commitgeschiedenis. Zo kun je naar twee commits voor de huidige verwijzen door de HEAD~2 shorthand te gebruiken:

git diff HEAD~2..HEAD

Git biedt ook verschillende andere manieren om naar commits te referren, zoals het gebruik van het “@” symbool om naar de huidige branch te referren of het gebruik van het “^” symbool om naar de parent van een commit te referren. Door deze shorthandnotaties te gebruiken, kun je tijd besparen en fouten vermijden als je met commits werkt.

8. Stashen

In normale omstandigheden zou je denken dat er geen manier is om wijzigingen die je in bestanden aanbrengt op te slaan zonder ze te committen. stashen is de manier om dit tijdelijk te doen. Het is handig als je van branch moet wisselen of aan een andere taak moet werken, maar je wijzigingen nog niet wilt committen.

Als je bijvoorbeeld van branch moet wisselen om aan iets te werken tijdens de flow, dan kun je de wijzigingen in de huidige branch stashen en de andere checkouten. Vanaf daar kun je aan de andere branch werken, dan die wijzigingen committen en pushen. Je kunt dan outchecken en je werk ophalen op de oorspronkelijke branch.

Er zijn twee manieren om wijzigingen op te slaan:

git stash

Dit slaat je wijzigingen op in een nieuwe stash, en zet je werkmap terug naar de laatste HEAD commit (de state waarin je het had voordat je nieuwe wijzigingen aanbracht). Je kunt de wijzigingen oplijsten met git stash list, en de stash inspecteren met git stash show. Dit laatste commando kan ook elk format accepteren dat git diff accepteert.

Vanaf hier kun je van branch wisselen of aan een andere taak werken. Als je je wijzigingen wilt ophalen, voer dan het volgende commando uit:

git stash apply

Dit zal de laatst gestashte wijzigingen toepassen op je werkmap. Houd er echter rekening mee dat je nog steeds conflicten kunt tegenkomen als je het bestand te veel wijzigt. git stash is tenslotte een tijdelijke oplossing voor het probleem.

Je kunt ook meerdere stashes hebben en je kunt aangeven welke stash je wilt toepassen met het volgende:

git stash apply stash@{n}

De placeholder {n} neemt een geheel getal, en stash@{0} vertegenwoordigt de laatste stash. De officiële Git documentatie bevat enkele andere voorbeelden van git stash.

9. Bisecten

We durven te wedden dat iedereen wel eens een bug of probleem tegengekomen is en geen idee had waar te beginnen met zoeken. In deze situaties kan ‘bisecting’ je helpen om snel de commit te identificeren die het probleem geïntroduceerd heeft.

In een notendop jaagt het commando bugs op door je commits te doorzoeken. Als het de overtredende commit gevonden heeft, zal het deze naar je terugsturen. De kracht van dit commando zit in alle subcommando’s die je kunt gebruiken.

Om bisecting te gebruiken, moet je eerst het git bisect start commando uitvoeren. Git zal je dan naar de eerste commit in de geschiedenis van je project brengen.

Vanaf hier moet je aangeven of die commit goed of slecht is door de relevante commando’s te gebruiken:

git bisect good

git bisect bad

Git zal je dan naar de volgende commit brengen om de ‘kwaliteit’ ervan te testen Merk op dat je “good” ook kunt vervangen door “old” en slecht door “new” om bij je specifieke gebruikssituatie te passen (hoewel je termen niet kunt mixen)

Vanaf hier kun je doorgaan met het markeren van iedere commit als goed of slecht totdat je de commit vindt die de bug introduceerde. Je hoeft echter niet iedere commit door te spitten – je kunt exacte identificaties opgeven om te helpen je zoekopdracht te verkleinen en te verkorten:

git bisect bad feature-test

Hier wordt een branchnaam gebruikt, maar het zou een specifieke revisie kunnen zijn met behulp van een geheel getal, een hash referentie, en meer. Hoe dan ook, zodra je de bug gevonden hebt, kun je één van de volgende commando’s uitvoeren om terug te gaan naar je laatste code:

git bisect reset

Zoals met alle geavanceerde Git commando’s op deze lijst, is er nog veel meer te leren, en de Git documentatie is hier essentieel leesvoer.

10. Branches vergelijken

Ons gedeelte over commitreferrals gaat onder andere over het gebruik van git diff. Nu is het tijd om dit in meer detail te bekijken. Je zult vaak meerdere branches hebben die verschillende wijzigingen bevatten. Git laat je de verschillen tussen twee branches vergelijken met het git diff commando. Je kunt ze op een aantal manieren gebruiken, vaak in combinatie met andere commando’s, om een repo te onderzoeken en analyseren.

Het basic git diff commando geeft je uitvoer met een overzicht van de wijzigingen. Het lijkt veel op de uitvoer van een commit merge onderzoek:

Je kunt echter inzoomen op exacte branches, hashes en meer. Om bijvoorbeeld twee branches te vergelijken, voer je het git diff branch1..branch2 commando uit, en vervang je de plaatsaanduidingen:

git diff feature-branch pre-prod

Je kunt ook de verschillen tussen je huidige branch en een andere branch vergelijken:

git diff HEAD..pre-prod

Merk op dat het gebruik van twee puntjes hier het verschil oplevert tussen de twee uiteinden van de branches. Drie puntjes daarentegen geeft het verschil tussen de gemeenschappelijke parent van beide branches en gebruikt dat om te testen.

Net als bij git log kun je de uitvoer opschonen en verfijnen wat het teruggeeft. Bijvoorbeeld, git diff --name-only branch1..branch2 zal alleen controleren welke bestanden verschillen en de context weglaten:

Je kunt merken dat de uitvoer moeilijk te parsen is, vooral als de ‘diff’ lang is. In deze gevallen kun je de --color-words optie gebruiken:

Over het algemeen kan git diff net zo krachtig zijn als andere commando’s, vooral als je bepaalde opties oproept en verfijnt welke verschillen je terugkrijgt.

11. Losse commits toepassen

Soms wil je een specifieke commit van een branch op een andere toepassen zonder de twee branches te mergen. Git laat je dit doen met git cherry-pick. Je moet hier voorzichtig mee omgaan, maar je zult merken dat git cherry-pick je in een paar scenario’s kan helpen.

Eén situatie is als je oudbakken feature branches hebt die je niet mergt in main of trunk. Je zou een combinatie van commando’s kunnen gebruiken (zoals git log) om oude relevante commits uit te graven en ze elders opnieuw toe te passen.

Gebruik git log om de referentie van een commit te vinden. Zorg er vanaf daar voor dat je op de branch zit waar je een referentie naar wilt cherrypicken. Bijvoorbeeld, stel dat je de commit xxxxxaaaaaa in de branch “trunk” wilt cherrypicken. Allereerst is het goed om je branch te checkouten.

git checkout trunk

…en cherrypick daarna je commit:

git cherry-pick xxxxxaaaaaa

Je commitbericht zal waarschijnlijk vaak verouderd zijn. Om dit op te lossen, kun je de --edit optie aan het commando meegeven. Dit zal je een nieuwe commitboodschap laten geven voordat je gaat cherrypicken.

12. Superchargen van ‘git add’

Voor ons laatste geavanceerde Git commando, gaan we je git add laten zien. Nee, dat is geen typefout – dit fundamentele Git commando heeft verrassende mogelijkheden onder de motorkap.

Als je bijvoorbeeld losse bestanden toevoegt aan het staginggebied, dan zou je het volgende kunnen gebruiken:

git add -p

De -p optie laat je wijzigingen op een interactieve basis stagen. Je kunt de wijzigingen die je in elk bestand hebt gemaakt bekijken en dan kiezen welke je wilt stagen. Dit kan je veel tijd besparen en je helpen voorkomen dat je een ongewenste wijziging staget.

Hoewel je misschien weet dat je individuele bestanden kunt stagen, kun je ook een map specificeren. Bijvoorbeeld, om alle bestanden in de “new-feature” map te stagen:

git add new-feature

Je wilt misschien zelfs zien wat het resultaat van een git add zal zijn zonder het proces volledig uit te voeren. Ook hier heb je een optie voor:

git add --dry-run

git add -n

Als je dit uitvoert, zal Git je laten zien of het de bestanden zal toevoegen of negeren. Over genegeerde bestanden gesproken, je kunt ze ook toevoegen aan het staginggebied als je dat wilt:

git add --force

git add -f

Bestanden toevoegen aan het staginggebied kan complexer zijn dan een simpel binair “Add or don’t add” scenario. Als zodanig kan een van Git’s meest kerncommando’s talloze eventualiteiten afdekken.

Samenvatting

Als je de basiscommando’s van Git onder de knie hebt, beschik je over 80 procent van wat je nodig hebt om de reguliere versiebeheertaken van je project uit te voeren. Maar de laatste 20 procent is waar de geavanceerde Git commando’s kunnen schitteren.

Commando’s en technieken zoals rebasen, bisecten, bestanden terugzetten en meer zullen je allemaal snel uit de problemen helpen. Sterker nog, je kunt meer waarde bieden aan je team en project, en je zou kunnen helpen bij het stroomlijnen van werkstromen, het verhogen van de productiviteit, en in het algemeen een groter effect hebben als developer.

Zal een van deze geavanceerde Git commando’s deel gaan uitmaken van je dagelijkse werk? Laat het ons weten in de commentsectie hieronder!