Git-Status: Überprüfen eines Repositorys

git status

Der Befehl git status gibt den Status des Arbeitsverzeichnisses und der Staging-Umgebung zurück. So kannst du sehen, welche Änderungen sich in der Staging-Umgebung befinden, welche nicht und welche Dateien nicht von Git verfolgt werden. Die Statusausgabe zeigt keine show Informationen bezüglich des committeten Projektverlaufs an. Hierfür wird der Befehl git log benötigt.

Zugehörige Git-Befehle

git tag
- Tags sind Referenzen, die auf bestimmte Zeitpunkte im Git-Verlauf verweisen. git tag wird im Allgemeinen verwendet, um einen Zeitpunkt im Verlauf zu erfassen, der für eine markierte Versionsfreigabe verwendet wird (z. B. v1.0.1).
git blame
- Die übergeordnete Funktion von git blame ist es, die Autoren-Metadaten für bestimmte committete Zeilen in einer Datei anzuzeigen. Dies wird genutzt, um den Verlauf von spezifischem Code zu untersuchen und Fragen dazu zu beantworten, wie und warum welcher Code zu einem Repository hinzugefügt wurde.
git log
- Der Befehl git log zeigt committete Snapshots an. Du kannst damit den Projektverlauf auflisten, ihn filtern und nach bestimmten Änderungen suchen.

Anwendung

git status

Lass dir anzeigen, welche Dateien in der Staging-Umgebung sind, welche nicht und welche nicht verfolgt werden.

Diskussion

git status ist ein relativ geradliniger Befehl. Er zeigt schlichtweg, was im Hinblick auf git add und git commit geschehen ist. Statusmeldungen enthalten auch relevante Informationen zum Staging und Unstaging von Dateien. In der Beispielausgabe sind die drei Hauptkategorien eines Aufrufs von git status zu sehen:

# 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

Ignorieren von Dateien

Nicht verfolgte Dateien lassen sich in zwei Kategorien einteilen. Entweder handelt es sich um Dateien, die dem Projekt gerade hinzugefügt und noch nicht committet wurden, oder es sind kompilierte Binärdateien wie .pyc, .obj, .exe usw. Während es sicherlich vorteilhaft ist, dass die Ausgabe von git status Dateien der ersten Kategorie enthält, erschweren Dateien der zweiten Kategorie den Überblick darüber, was im Repository vor sich geht.

Aus diesem Grund bietet Git die Möglichkeit, Dateien komplett zu ignorieren, indem Pfade in einer speziellen Datei namens .gitignore platziert werden. Alle Dateien, die ignoriert werden sollen, lassen sich hier in separaten Zeilen definieren; das Sternsymbol * kann als Wildcard genutzt werden. Beispielsweise führt die folgende Zeile in einer .gitignore-Datei im Root-Verzeichnis des Projekts dazu, dass kompilierte Python-Module nicht vongit status angezeigt werden:

*.pyc

Beispiel

Es hat sich bewährt, den Status deines Repositorys vor dem Commit von Änderungen zu überprüfen, damit du nicht aus Versehen etwas committest, was du nicht wolltest. In diesem Beispiel ist der Repository-Status vor und nach dem Staging und Committen eines Snapshots zu sehen:

# 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)

Die erste Statusausgabe wird anzeigen, dass sich die Datei noch nicht in der Staging-Umgebung befindet. Die Aktion von git add wird im zweiten git status wiedergegeben und die finale Statusausgabe teilt dir mit, dass nichts zu committen ist – das Arbeitsverzeichnis stimmt mit dem letzten Commit überein. Einige Git-Befehle (z. B. git merge) erfordern ein sauberes Arbeitsverzeichnis, damit du nicht versehentlich Änderungen überschreibst.

git log

Der Befehl git log zeigt Snapshots an, die committet wurden. Du kannst damit den Projektverlauf aufrufen, ihn filtern und nach bestimmten Änderungen suchen. Während du mit git status das Arbeitsverzeichnis und die Staging-Umgebung ansiehst, beschränkt sich git log ausschließlich auf den Commit-Verlauf.

Die Protokollausgabe kann auf mehrere Arten angepasst werden – vom einfachen Filtern von Commits bis zur Anzeige in einem völlig benutzerdefinierten Format. Im Folgenden werden einige der gebräuchlichsten Konfigurationen von git log vorgestellt.

Anwendung

git log

Lass dir den gesamten Commit-Verlauf im Standardformat anzeigen. Wenn die Ausgabe über einen Bildschirm hinausgeht, kannst du mit der Leertaste herunterscrollen und sie mit q wieder verlassen.

git log -n <limit>

Begrenze die Anzahl der Commits mit . Beispielsweise werden bei der Eingabe von git log -n 3 nur drei Commits angezeigt.

Fasse jeden Commit in einer Zeile zusammen. Dies ist hilfreich, um einen groben Überblick über den Projektverlauf zu erhalten.

git log --oneline

git log --stat

Gib neben den üblichen git log-Informationen die geänderten Dateien sowie die relative Anzahl an Zeilen an, die ihnen hinzugefügt oder aus ihnen gelöscht wurden.

git log -p

Zeigt den Patch an, der den jeweiligen Commit repräsentiert. Du erhältst die volle Diff-Ansicht für jeden Commit, d. h. die detaillierteste Ansicht deines Projektverlaufs.

git log --author="<pattern>"

Suche nach Commits von einem bestimmten Autor. Das -Argument kann ein einfacher String oder ein regulärer Ausdruck sein.

git log --grep="<pattern>"

Suche nach Commits mit einer Commit-Nachricht, die mit dem übereinstimmt. Dieses kann ein einfacher String oder ein regulärer Ausdruck sein.

git log <since>..<until>

Dieser Befehl zeigt nur Commits, die (seit) und (bis) zu einem bestimmten Zeitpunkt durchgeführt wurden. Beide Argumente können entweder eine Commit-ID, ein Branch-Name, ein HEAD oder eine beliebige andere Revisionsreferenz sein.

git log <file>

Lass dir nur Commits anzeigen, die die angegebene Datei enthalten. Auf diese Weise kann bequem der Verlauf einer bestimmten Datei angesehen werden.

git log --graph --decorate --oneline

Außerdem kannst du auf die folgenden nützlichen Optionen zurückgreifen: Die Option --graph erstellt auf der linken Seite der Commit-Nachrichten einen textbasierten Graphen der Commits. --decorate fügt die Namen der angezeigten Branches bzw. die Tags der Commits hinzu. --oneline zeigt Commit-Informationen in einer Zeile für ein leichteres Durchsuchen der Commits auf einen Blick.

Diskussion

Der Befehl git log ist das grundlegende Werkzeug zum Durchsuchen eines Repository-Verlaufs. Hiermit suchst du nach einer bestimmten Projektversion oder findest heraus, welche Änderungen in einen Feature Branch gemergt werden müssen.

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

Das meiste ist recht offensichtlich, die erste Zeile erfordert jedoch eine zusätzliche Erklärung. Der 40 Zeichen lange String nach commit ist eine SHA-1-Prüfsumme der Inhalte des Commits. Dies dient zwei Zwecken. Erstens wird die Integrität des Commits sichergestellt – sollte er korrumpiert sein, würde der Commit eine andere Prüfsumme generieren. Zweitens dient sie als eindeutige ID für den Commit.

Diese ID kann in Befehlen wie git log .. verwendet werden, um auf einen bestimmten Commit zu verweisen. git log 3157e..5ab91 wird z. B. alles zwischen den Commits mit den IDs 3157e und 5ab91 anzeigen. Neben Prüfsummen sind Branch-Namen (im Modul zu den Branches besprochen) und HEAD weitere gebräuchliche Methoden zum Verweisen auf einen bestimmten Commit. HEAD bezieht sich immer auf den aktuellen Commit, ob dies nun ein Branch oder ein bestimmter Commit ist.

Das Zeichen ~ ist nützlich zur Angabe von relativen Referenzen zum Parent. 3157e~1 referenziert z. B. den Commit vor 3157e und HEAD~3 ist drei Stellen vor dem aktuellen Commit (Great-Grandparent).

Diese Identifikationsmethode ermöglicht die Durchführung von Aktionen, die sich auf einen bestimmten Commit beziehen. Der Befehl git log ist normalerweise der Ausgangspunkt für derartige Interaktionen, da über ihn die Commits gefunden werden können, mit denen du arbeiten möchtest.

Beispiel

Im Abschnitt Nutzung findest du einige Beispiele für git log, aber denke daran, dass mehrere Optionen in einem einzigen Befehl kombiniert werden können:

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

Hiermit wird eine vollständige Diff-Ansicht aller Änderungen, die John Smith an der Datei hello.py vorgenommen hat, angezeigt.

Die Syntax .. ist äußerst hilfreich für den Vergleich von Branches. Das nächste Beispiel zeigt einen kurzen Überblick aller Commits, die sich in some-feature, aber nicht in main befinden.