git status: een repository inspecteren

git status

De opdracht git status toont de status van de werkmap en het staginggebied. Zo kun je zien welke wijzigingen zijn gestaged en welke niet, en welke bestanden niet worden bijgehouden door Git. De statusuitvoer toont je geen informatie over de gecommitte projectgeschiedenis. Hiervoor heb je git log nodig.

Gerelateerde Git-opdrachten

git tag
- Tags zijn verwijzingen naar specifieke punten in de geschiedenis van Git. git tag wordt over het algemeen gebruikt om een punt in de geschiedenis vast te leggen dat wordt gebruikt voor een gemarkeerde versierelease (d.w.z. v1.0.1).
git blame
- De functie op hoog niveau van git blame is het weergeven van metagegevens van een auteur die zijn gekoppeld aan specifieke, gecommitte regels in een bestand. Dit wordt gebruikt om de geschiedenis van specifieke code te verkennen en om vragen te beantwoorden over wat, hoe en waarom de code werd toegevoegd aan een repository.
git log
- Met de opdracht git log kun je gecommitte momentopnamen weergeven. Je kunt de projectgeschiedenis weergeven, deze filteren en erin zoeken naar specifieke wijzigingen.

Gebruik

git status

Toont een lijst met bestanden die gestaged, niet-gestaged en niet-getraceerd zijn.

Bespreking

De opdracht git status is een relatief eenvoudige opdracht. De opdracht laat zien wat er is gebeurd met git add en git commit. Statusberichten bevatten ook relevante instructies voor het stagen/ontstagen van bestanden. Hieronder vind je een voorbeelduitvoer met de drie belangrijkste categorieën van een git status-aanroep:

# On branch main
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#hello.pyc

Bestanden negeren

Niet-getraceerde bestanden kunnen doorgaans in twee categorieën worden onderverdeeld. Het zijn ofwel bestanden die net aan het project zijn toegevoegd en nog niet zijn vastgelegd, of het zijn gecompileerde binaire bestanden zoals .pyc, .obj, .exe, etc. Hoewel het zeker nuttig is om de eerste op te nemen in de git status-uitvoer, kan de laatste het moeilijk maken om te zien wat er werkelijk gebeurt in je repository.

Om deze reden kun je met Git bestanden volledig negeren door paden te plaatsen in een speciaal bestand genaamd .gitignore. Alle bestanden die je wilt negeren, moeten op een aparte regel worden geplaatst, waarbij het symbool * als jokerteken kan worden gebruikt. Als je bijvoorbeeld het volgende toevoegt aan een bestand .gitignore in de hoofdmap van je project, voorkomt dit dat gecompileerde Python-modules in git status verschijnen:

*.pyc

Voorbeeld

Het is een goede gewoonte om de status van je repository te controleren voordat je wijzigingen doorvoert, zodat je niet per ongeluk iets commit wat je niet wilt. Dit voorbeeld toont de status van de repository voor en na het stagen en committen van een momentopname:

# Edit hello.py
git status
# hello.py is listed under "Changes not staged for commit"
git add hello.py
git status
# hello.py is listed under "Changes to be committed"
git commit
git status
# nothing to commit (working directory clean)

De eerste statusuitvoer toont het bestand als 'unstaged'. De actie git add wordt weergegeven in de tweede git status, terwijl de uiteindelijke statusuitvoer aangeeft dat je niets hoeft te committen: de werkmap komt overeen met de meest recente commit. Voor sommige Git-opdrachten (bijvoorbeeld git merge) moet de werkmap leeg zijn, zodat je niet per ongeluk wijzigingen overschrijft.

git log

Met de opdracht git log kun je gecommitte momentopnamen weergeven. Je kunt er de projectgeschiedenis mee weergeven, deze filteren en erin zoeken naar specifieke wijzigingen. Terwijl je met git status de werkdirectory en het staginggebied kunt inspecteren, toont git log alleen de gecommitte geschiedenis.

De loguitvoer kan op verschillende manieren worden aangepast, van simpelweg het filteren van commits tot het weergeven van logbestanden in een volledig door de gebruiker gedefinieerde indeling. Enkele van de meest voorkomende configuraties van git log worden hieronder gepresenteerd.

Gebruik

git log

Geeft de volledige commit-geschiedenis weer in de standaardindeling. Als de uitvoer meer dan één scherm in beslag neemt, kun je de space gebruiken om te scrollen en q om af te sluiten.

git log -n <limit>

Het aantal commits beperken tot . Met git log -n 3 worden bijvoorbeeld maar 3 commits weergegeven.

Comprimeert elke commit tot één regel. Dit is erg handig om een algemeen overzicht van je project te krijgen.

git log --oneline

git log --stat

Vermeldt samen met de gewone git log-gegevens welke bestanden zijn gewijzigd en het relatieve aantal regels dat is toegevoegd aan of verwijderd uit elk bestand.

git log -p

Geeft de patch weer die elke commit vertegenwoordigt. Dit toont het volledige verschil van elke commit, wat de meest gedetailleerde weergave is die je kunt krijgen van je projectgeschiedenis.

git log --author="<pattern>"

Naar commits van een bepaalde auteur zoeken. Het argument kan een gewone tekenreeks of een reguliere expressie zijn.

git log --grep="<pattern>"

Zoeken naar commits met een commit-bericht dat overeenkomt met een , dat een gewone tekenreeks of een reguliere expressie kan zijn.

git log <since>..<until>

Toont alleen commits die plaatsvinden tussen en . Beide argumenten kunnen een commit-ID, de naam van een branch, HEAD of een andere revisiereferentie zijn.

git log <file>

Toont alleen commits die het gespecificeerde bestand bevatten. Dit is een eenvoudige manier om de geschiedenis van een bepaald bestand te bekijken.

git log --graph --decorate --oneline

Een paar handige opties om te overwegen. De markering --graph die links van de commit-berichten een tekstgrafiek van de commits tekent. --decorate voegt de namen toe van de branches of tags van de commits die worden getoond. --oneline toont de commit-informatie op één regel, zodat het makkelijker is om in één oogopslag door commits te bladeren.

Bespreking

De opdracht git log is de basistool van Git om de geschiedenis van een repository te verkennen. Het is de tool die je gebruikt als je een specifieke versie van een project wilt vinden of wilt uitzoeken welke wijzigingen er worden geïntroduceerd als je iets samenvoegt in een functiebranch.

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

Het meeste hiervan is vrij eenvoudig, maar de eerste regel verdient enige uitleg. De reeks van 40 tekens na commit is een SHA-1-checksum van de inhoud van de commit. Dit dient twee doelen. Ten eerste waarborgt het de integriteit van de commit: als die ooit beschadigd zou raken, zou de commit een andere checksum genereren. Ten tweede dient hij als een unieke ID voor de commit.

Deze kan worden gebruikt in opdrachten zoals git log .. om te verwijzen naar specifieke commits. In git log 3157e..5ab91 wordt bijvoorbeeld alles weergegeven tussen commits met de ID's 3157e en 5ab91. Naast checksums zijn de namen van branches (besproken in de Branchmodule) en het sleutelwoord HEAD andere veelgebruikte methoden om naar individuele commits te verwijzen. HEAD verwijst altijd naar de huidige commit, of het nu een branch is of een specifieke commit.

Het teken ~ is nuttig om relatieve verwijzingen te maken naar het bovenliggende element van een commit. 3157e~1 verwijst bijvoorbeeld naar de commit vóór 3157e, en HEAD~3 ligt drie niveaus hoger dan de huidige commit.

Het idee achter al deze identificatiemethoden is om je acties te laten uitvoeren op basis van specifieke commits. De opdracht git log is doorgaans het startpunt voor deze interacties, omdat je hiermee de commits kunt vinden waarmee je wilt werken.

Voorbeeld

Het gedeelte Usage bevat veel voorbeelden van git log, maar vergeet niet dat verschillende opties kunnen worden gecombineerd tot één opdracht:

git log --author="John Smith" -p hello.py

Hiermee wordt een volledige diff weergegeven van alle wijzigingen die John Smith heeft aangebracht in het bestand hello.py.

De syntaxis .. is een zeer nuttig hulpmiddel om branches te vergelijken. Het volgende voorbeeld toont een kort overzicht van alle commits in some-feature die niet in de main zitten.