GitHub-branches maken: zo werkt de staging area

© PXimport

GitHub-branches maken: zo werkt de staging area

Geplaatst: 27 april 2022 - 04:38

Aangepast: 17 november 2022 - 08:55

Gertjan Groen

Bij het werken met Git moet je vooral wennen aan de zogeheten staging area, een soort tijdelijke opslag. Het is een krachtig hulpmiddel, maar ook lastig te doorgronden als je net begint. In deze workshop geven we tips hoe je dit optimaal benut. Wil je GitHub-branches maken, dan geven wij hier ook wat tips voor.

Bij Git zet je wijzigingen eerst in een zogeheten staging area, een soort tijdelijke opslag, voordat je met een zogenoemde commit de wijzigingen naar je repository overzet. Je kunt hier gemakkelijk in verdwalen. In deze workshop geven we belangrijke tips om het werken op de verschillende niveaus van Git wat comfortabeler te maken!

Overzicht niveaus

Bij het werken met Git is het handig om de onderstaande afbeelding met het overzicht als een soort cheatsheet te gebruiken. Het geeft de verschillende niveaus weer, te weten: je werkdirectory met je programmabestanden, de staging area van Git met tussentijdse wijzigingen, je lokale repository op het systeem en eventueel nog een remote repository zoals GitHub. Je ziet ook de belangrijkste opdrachten die je tussen die niveaus kunt geven. Zo zie je git add waarmee je een bepaald bestand naar de staging area kunt zetten. Met de vlag -u in git add -u hoef je geen bestandsnaam op te geven, maar worden in één handeling de wijzigingen in gevolgde bestanden naar de staging area gezet. En je ziet de opdracht git commit waarmee je wijzigingen doorzet van de staging area naar de lokale repository, waarna de staging area weer leeg is en je aan de volgende veranderingen kunt gaan werken.

Overzicht met de verschillende niveaus waarop Git werkt.

© PXimport

Werken zonder staging area

Eventueel kun je zonder staging area werken als je die niet nodig denkt te hebben. Het werkt dan meer in lijn met Subversion (svn), een bekend alternatief voor Git. Je kunt namelijk, zoals je ook in het overzicht ziet, met één opdracht de beide opdrachten git add en git commit combineren in één opdracht waarmee je dus de staging area overslaat:

git commit -a

Je kunt hierbij ook een beschrijving toevoegen met:

git commit -am "Beschrijving van de aanpassing"

Het lukt overigens alleen voor bestanden die je al volgt, dus waar je eerder de opdracht git add hebt gegeven. Een enkele keer is dit handig, maar meestal zul je de staging area willen gebruiken.

Bij een commit kun je eventueel de staging area overslaan.

© PXimport

Veranderingen bekijken

Tijdens het werken met Git komt de opdracht git status van pas, waarmee je kunt zien welke bestanden zijn veranderd in je werkdirectory ten opzichte van de staging area. Wil je precies zien welke veranderingen dat zijn, dan gebruik je git diff, eventueel gevolgd door de bestandsnaam. Een rode regel met minteken ervoor geeft aan dat die regel is verwijderd. Daaronder zie je dan in het groen de nieuwe regel met een plusteken ervoor. Wil je zien welke veranderingen je in de staging area hebt klaargezet, dan geef je de opdracht (eventueel gevolgd door een bestandsnaam):

git diff --staged

Wijzigingen ongedaan maken

Stel dat je een wijziging hebt gedaan aan bepaalde programmacode in de werkdirectory, maar je bent hier niet tevreden mee? Als voorbeeld hebben we enkele regels toegevoegd die de huidige datum en tijd op het scherm te tonen. Je ziet welke veranderingen er zijn ten opzichte van de versie in de staging area met de opdracht:

git diff demo.go

Deze opdracht laat in de output weer de toegevoegde regels in het groen zien en de verwijderde regels in het rood. Zoals je ook in het overzicht hierboven kunt zien, kun je de versie uit de staging area terugzetten met:

git checkout demo.go

De veranderingen zijn nu ongedaan gemaakt. Je kunt ook eerdere commits terugzetten (zie volgende twee paragrafen).

Eerdere commits

Om terug te gaan naar een van de eerdere commits, is het handig eerst een lijst met eerdere commits op te vragen. Daarna kun je eventueel vergelijkingen maken. Als voorbeeld hebben we de datum/tijdmelding weer toegevoegd aan de programmacode, eerst in het rfc850-formaat en daarna in het rfc3339-formaat. Beide veranderingen hebben we gecommit. Met git log kun je een lijst met alle historische commits opvragen. Dit kan eventueel in één regel per commit met:

git log --oneline

Je ziet hierbij dat een zogenoemde hash aan elke commit is toegekend als referentie en het eerste unieke gedeelte van die hash gaan we gebruiken. De laatste commit is altijd bekend onder de naam HEAD. Je kunt vergelijkingen maken tussen commits. Benoem dan de twee commits die je wil vergelijken door ofwel HEAD of de hash in te vullen, bijvoorbeeld:

git diff HEAD b9eebfe

Git kan een overzicht van eerdere commits met beschrijving geven.

© PXimport

Commit terugzetten

Om een commit terug te zetten, heb je meerdere opties. Zo kun je een reset-opdracht geven waar je dan (een deel van) de hash achter zet, bijvoorbeeld:

git reset --hard b9eebfe

Na deze opdracht bestaan de latere commits in feite niet meer, alsof ze nooit hebben plaatsgevonden. Ook ben je alle niet-toegevoegde veranderingen in je werkdirectory kwijt! Je kunt als veiliger alternatief een checkout-opdracht gebruiken met daarachter ofwel HEAD voor de laatste commit ofwel de hash voor een specifieke commit, bijvoorbeeld:

git checkout HEAD

Hierbij worden de bestanden in je werkdirectory aangepast naar de bewuste commit. Om eventueel weer terug naar de eerdere hoofdtak gebruik je:

git checkout master

Vertakkingen

De checkout die we hierboven noemden, kom je vooral tegen bij het werken met vertakkingen ofwel branches. Stel dat je de commit met hash b9eebfe de naam rfc850-branch wil geven, dan geef je de opdracht:

git checkout -b rfc850-branch b9eebfe

Hiermee wordt dankzij de optie -b automatisch de nieuwe branch rfc850-branch aangemaakt en wordt vervolgens de werkdirectory aangepast naar de bewuste commit met de hash b9eebfe. Je werkt dan in deze vertakking, waar je uiteraard ook weer commits kunt gaan maken. Zoals eerder gezegd, kun je eventueel weer terug naar de master, in feite de hoofdtak, met:

git checkout master

Om in het vervolg direct naar de vertakking rfc850-branch te gaan, gebruik je:

git checkout rfc850-branch

Zulke vertakkingen zul je vooral gebruiken om functies apart van de master uit te werken die je later eventueel weer toevoegt aan die master, ook wel ‘merge’ genoemd.

Je kunt je vertakkingen een naam geven en hier los van de hoofdtak aan werken.

© PXimport

Deel dit artikel
Voeg toe aan favorieten