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).
- Tags sind Referenzen, die auf bestimmte Zeitpunkte im Git-Verlauf verweisen.
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.
- Die übergeordnete Funktion von
- git log
- Der Befehl
git log
zeigt committete Snapshots an. Du kannst damit den Projektverlauf auflisten, ihn filtern und nach bestimmten Änderungen suchen.
- Der Befehl
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.
git log --oneline main..some-feature