Git CLI en Theoretische Fundamenten

We hebben GitHub (de web-interface) en GitHub Desktop gebruikt om een Git repo aan te maken, wijzigingen op te slaan (commit), de repo lokaal te krijgen (clone) en lokale aanpassingen naar GitHub door te sturen (push).

In dit hoofdstuk zetten we eerst een stapje terug door met de Git CLI (Command Line Interface) te leren werken. We doen dit initieel volledig lokaal. We leren de basisconcepten van Git zelf en commando's die je dagelijks gebruikt.

De CLI:

• Is altijd en overal bruikbaar
• Werkt precies hetzelfde op elk platform
• Helpt je de fundamenten te begrijpen
• Wordt veel gebruikt door AI Agents

Git CLI Installeren¶

brew install git

sudo apt-get install git

sudo dnf install git

Testen¶

Vanuit een terminal (Cmd of Powershell voor Windows):

Dit werkt ook in een terminal die je rechtstreeks in VS Code opent (View → Terminal of CTRL+`/CMD+`).

Documentatie¶

De Git documentatie is erg goed en een handige bron om bij de hand te hebben.

• On-line: https://git-scm.com/docs
• Met het git commando: git help.

git help

git help -a

git help commit

Het uitstekende boek Pro Git is gratis beschikbaar, zowel online als in PDF of ePub formaat.

Basis Configuratie¶

We komen later terug op configuratiemogelijkheden van Git. Om verder te werken is het belangrijk eerst een aantal basisinstellingen aan te passen. Gebruik in onderstaande commando's je eigen naam en email adres.

git config --global user.name "John Doe"

git config --global user.email "john.doe@gmail.com"

git config --global init.defaultBranch main

Wat een defaultBranch precies is en waarom we dit aanpassen komt ook later nog aan bod.

Git Repository¶

Één directory (folder of map) = één git repo

Je kan van elke directory een Git repo maken. Die directory hoeft niet leeg te zijn.

In VS Code maken we een nieuwe directory om in te werken. In het startscherm kies je Open..., ofwel File → Open in het menu (= CTRL+O / CMD+O). Maak een nieuwe directory met een naam naar keuze (bvb. hello) en open deze.

In VS Code voeg je dan volgende bestanden toe:

# My first Git repo

print("Hello from Git")

Repository Aanmaken - init¶

Om de Git CLI te gebruiken hebben we een terminal nodig. Dit kan via een aparte applicatie (Terminal applicatie in Linux/macOS; WSL, Cmd of Powershell in Windows). Maar je kan ook rechtstreeks in VS Code een terminal openen via View → Terminal (of CTRL+` / CMD+`).

Om een Git repo te maken (initialiseren) gebruik je het commando git init (in de directory):

Het commando git status geeft informatie over de repo en zullen we nog veel gebruiken:

In de output zie je dat we op de branch (tak, zoals de tak van een boom) genaamd main zitten. Een branch kan je zien als één bepaalde lijst met versies (commits) van de code. Om te beginnen zal dit altijd main zijn. Wat een branch precies is, en hoe je er mee werkt, komt later nog uitgebreid aan bod.

Lifecycle van een Bestand¶

In Git bevindt elk bestand zich altijd in één bepaalde state (staat, of status). Via de verschillende commando's kan die state veranderen.

Elk bestand begint in de untracked state. Dit zien we duidelijk in de output van het git status commando. Dit betekent dat het bestand nog onbekend is voor Git.

Eenmaal een bestand gekend is zal het altijd in één van de drie mogelijke states verkeren: modified, staged of committed

git add¶

Om een nieuw bestand toe te voegen aan de Git repo gebruik je eerst het commando git add. De state van het bestand verandert dan naar staged. Het bestand zit dan in de zogenoemde staging area. In de staging area verzamel je een groep bestanden en wijzigingen die als één transactie toegevoegd zullen worden in het versie-systeem. Het is dus een soort wachtplaats.

In GitHub Desktop deden we dit door bestanden aan of af te vinken.

git commit¶

Nadat de gewenste bestanden en wijzigingen zijn klaargezet in de staging area kunnen ze als één geheel worden toegevoegd aan de Git-history met het commando git commit. Met het argument -m/--message geef je een beschrijving van de wijzigingen.

git status vertelt ons hier dat de working tree clean is. De working tree (of working directory) is de verzameling bestanden die overeenkomt met de huidige branch (of commit). M.a.w. de bestanden die je op dat moment in de directory van je repo kan zien en gebruiken. De working tree is "clean" wanneer er geen veranderingen zijn t.o.v. de gecommitte versie.

Oefening¶

Maak een kleine aanpassing in hello.py. Gebruik git status om te bevestigen dat de state van hello.py nu modified is.

Stage deze aanpassing alsook het README.md bestand. Commit dan de aanpassingen. Controleer het resultaat met git status

message = "Hello from my first Git repo"
print(message)

git rm¶

Het kan gebeuren dat een bestand per ongeluk in de Git-history is beland. Of gewoon niet meer nodig is. Om een bestand uit Git te verwijderen gebruik je het git rm commando.

Net als bij git add wordt het te verwijderen bestand eerst toegevoegd aan de staging area. Om de verwijdering (samen met eventuele andere aanpassingen) effectief door te voeren gebruiken we opnieuw git commit

Commit Geschiedenis (History)¶

Elke commit bevat de volgende informatie:

• ID
• Auteur (wie)
• Datum (wanneer)
• Beschrijving (waarom)
• Diff (wat)

git log¶

Met het git log commando kan je de commit geschiedenis bekijken, vanaf de laatste commit. Met het commando git help log zie je dat er erg veel opties en mogelijkheden zijn. We bekijken hier de meest gebruikte.

(HEAD is een reference en main is een branch - hier komen we later op terug)

--oneline optie¶

Met git log --oneline krijg je, zoals te verwachten, een enkele lijn per commit.

Je ziet dat de commit ID ingekort is tot de eerste 7 karakters. Dit is hier genoeg om een unieke commit aan te duiden.

--stat optie¶

Met git log --stat krijg je voor elke commit de "statistieken" van de wijzigingen: welke bestanden, hoeveel lijnen en het soort wijziging.

Je kan de opties vaak ook combineren. Zo zal git log --oneline --stat de commit informatie op 1 lijn plaatsen, gevolgd door de statistieken.

filename argument¶

Door na het git log commando een bestandsnaam te plaatsen krijgen we enkel de commits te zien die betrekking hebben op dat bestand.

Veranderingen ongedaan maken¶

git restore¶

Met git restore kan je veranderingen die nog niet gestaged zijn ongedaan maken. In het lifecycle diagram: van modified naar committed.

Merk op dat de output van git status je het juiste commando al aangeeft.

Na een ongewenste verandering in hello.py:

Unstage (git restore --staged)¶

Met git restore --staged kan je veranderingen die wel al gestaged zijn ongedaan maken. In het lifecycle diagram: van staged naar modified.

Opnieuw krijg je van git status het geschikte commando.

Na een ongewenste verandering in hello.py:

Veranderingen Bekijken¶

Git houdt alle versies en details superefficient bij. Het is dan ook belangrijk om snel en gemakkelijk specifieke versies en verschillen te kunnen ophalen.

Een diff is een weergave van de verschillen tussen twee versies van een of meerdere bestand(en), waarbij zichtbaar wordt welke regels zijn toegevoegd, gewijzigd of verwijderd. Een diff is niet specifiek aan Git -- zo zal het Linux commando diff a.txt b.txt de verschillen weergeven tussen de bestanden a.txt en b.txt.

Nieuwe wijzigingen¶

Wijzigingen die nog niet gestaged zijn bekijk je met het git diff commando.

Na het toevoegen van een regel in README.md:

Om de wijzigingen die wel al gestaged zijn te zien gebruik je het git diff --staged commando.

Bestaande Commits en Diffs¶

Om de inhoud van een bestaande commit te bekijken is er het commando git show.

Met git log -p (-p voor patch) krijgen we dezelfde informatie voor een lijst commits.

Met git diff kunnen we ook een diff krijgen met alle wijzigingen tussen twee specifieke commits.

git diff f39a6cc..3ecf8d5 geeft alle verschillende tussen de commits f39a6cc en 3ecf8d5.

Git Blame¶

git blame (letterlijk beschuldigen) is een superhandig commando waarmee je lijn per lijn precies kan zien wie als laatste die lijn heeft aangepast, wat de commit ID is, en wanneer dit gebeurd is.

Ons klein test-projectje bevat natuurlijk niet veel veranderingen. Wil je een idee krijgen van de kracht van dit commando, bekijk dan eens een grotere codebase zoals FastAPI: https://github.com/fastapi/fastapi/blame/master/fastapi/openapi/models.py.

Oefeningen¶

1. Voeg een nieuw bestand test.py toe (commit)
2. Pas iets aan in README.md en test.py
3. Stage de aanpassingen in README.md
4. Bekijk de commit geschiedenis en status van de repo
5. Bekijk de uitstaande aanpassingen
6. Maak alle uitstaande aanpassingen ongedaan. Gebruik enkel git commando's.
7. Verwijder het test.py bestand en commit deze verandering

Configuratie¶

git config¶

Git heeft een heleboel configuratieparameters. De meesten zul je echter nooit moeten aanpassen.

De configuratie wordt bewaard in gewone tekst-bestanden en kan op 3 locaties voorkomen. Elke locatie overschrijft de waarden van de vorige.

Die bestanden pas je in principe niet met de hand aan. Met het git config commando kunnen we configuratie bekijken en aanpassen.

Met git help -c krijg je een lijst van alle mogelijke parameters. Om te beginnen zijn er maar een paar die we willen aanpassen.

Identiteit¶

De user.name en user.email parameters worden gebruikt in commits. Hier willen we onze eigen identiteit instellen - zeker in repos waar we onze code willen delen, of waar we zullen samenwerken met andere ontwikkelaars.

Omdat dit in principe hetzelfde zal zijn voor elke repo gebruiken we --global. Met git config get kunnen we de waarde van een parameter controleren.

Editor¶

Soms heeft een Git commando tekst input nodig van de gebruiker. Bijvoorbeeld bij het git commit commando wanneer geen commit message is meegegeven met de -m parameter. Git zal dan je tekst editor openen zodat je daar een commit message kan samenstellen.

Op Linux, macOS en WSL zal dit standaard de waarde van de $EDITOR variabele zijn (meestal vim of emacs). Als je met vim kan werken is dat een goede optie. Met de core.editor configuratie parameter kunnen we Git een andere editor laten gebruiken.

Bijvoorbeeld om VS Code te gebruiken op Linux, macOS of Windows:

Configuratie overzicht¶

Met git config --list --show-origin krijg je een overzicht van alle aangepaste configuratie en waar die configuratie ingesteld is.

Bestanden negeren (.gitignore)¶

Er zullen altijd een aantal bestanden of directories zijn die je nooit wilt committen. Je kan Git configureren om deze altijd te negeren m.b.v. het .gitignore bestand. Hierin plaats je telkens op een aparte lijn de naam of een expressie van wat genegeerd moet worden.

Het .gitignore bestand zelf voeg je wel toe in Git.

__pycache__/
.vscode/
*.temp

Samenvatting¶