Close

Git-Status: Überprüfen eines Git-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 Git-Repository hinzugefügt wurde.
  • git log
    • Der Befehl git log zeigt committete Snapshots an. Du kannst mit "git log" den Projektverlauf auflisten, ihn filtern und nach bestimmten Änderungen suchen.
Git-Logo
Zugehöriges Material

Git-Merkzettel

Bitbucket-Logo
Lösung anzeigen

Git kennenlernen mit Bitbucket Cloud

Anwendung von "git rebase"

git status

Mit dem Befehl "git status" kannst du dir anzeigen lassen, 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

Dateien beim Ausführen von "git status" ignorieren

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

The first status output will show the file as unstaged. The git add action will be reflected in the second git status, and the final status output will tell you that there is nothing to commit—the working directory matches the most recent commit. Some Git commands (e.g., git merge) require the working directory to be clean so that you don't accidentally overwrite changes.

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 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 von "git rebase"

git log

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

git log -n <limit>

Mit "git log -n" begrenzt du die Anzahl der Commits. 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

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

Search for commits by a particular author. The <pattern> argument can be a plain string or a regular expression.

git log --grep="<pattern>"

Search for commits with a commit message that matches <pattern>, which can be a plain string or a regular expression.

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>

Mit "git log " kannst dir nur Commits anzeigen lassen, 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

5. Überprüfe den Status der Datei.

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

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

Diesen Artikel teilen
Nächstes Thema

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Mitarbeiter arbeiten mit unzähligen Tools zusammen

Bitbucket-Blog

Abbildung: DevOps

DevOps-Lernpfad

Demo Den: Feature-Demos mit Atlassian-Experten

So funktioniert Bitbucket Cloud mit Atlassian Open DevOps

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up