Ein Repository überprüfen

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 Informationen bezüglich des committeten Projektverlaufs an. Hierfür wird der Befehl git log benötigt.

Zugehörige Git-Befehle

  • git tag
    • Tags sind Refs, die auf bestimmte Punkte im Git-Verlauf verweisen. In der Regel werden mit git tag bestimmte Punkte im Verlauf erfasst, die für einen markierten Versions-Release (i.e. v1.0.1) verwendet werden.
  • git blame
    • Die übergeordnete Funktion von git blame ist es, die Autoren-Metadaten für bestimmte Befehlszeilen in einer Datei anzuzeigen. Dies wird genutzt, um den Verlauf von bestimmtem Code zu sehen und Fragen dazu zu beantworten, welcher Code wie und warum zu einem Repository hinzugefügt wurde.
  • 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.

Anwendung

git status

Zeigt an, 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 master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # #modified: hello.py # # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # #modified: main.py # # Untracked files: # (use "git add ..." 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 Platzhalter genutzt werden. Beispielsweise führt die folgende Zeile in einer .gitignore-Datei im Root-Verzeichnis des Projekts dazu, dass kompilierte Python-Module nicht von git 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.

Git-Tutorial: git status vs. git log

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

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

git log -n 

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

git log --oneline

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

git log --stat

Gibt 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=""

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

git log --grep=""

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

git log ..

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 

Zeigt nur die Commits an, 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 von Git zum Durchsuchen eines Repository-Verlaufs. Hiermit suchst du nach einer bestimmten Projektversion oder findest heraus, welche Änderungen durch das Mergen in einen Feature Branch eingeführt werden.

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 eines Commits. 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 master befinden.

git log --oneline master..some-feature

Möchtest du dich mit "git status" vertraut machen?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen