English ▾ Themen ▾ Neueste Version ▾ git-status zuletzt aktualisiert in 2.45.0

NAME

git-status - Zeigt den Status des Arbeitsverzeichnisses an

SYNOPSIS

git status [<options>] [--] [<pathspec>…​]

BESCHREIBUNG

Zeigt Pfade an, die Unterschiede zwischen der Indexdatei und dem aktuellen HEAD-Commit aufweisen, Pfade, die Unterschiede zwischen dem Arbeitsverzeichnis und der Indexdatei aufweisen, und Pfade im Arbeitsverzeichnis, die von Git nicht verfolgt werden (und nicht von gitignore[5] ignoriert werden). Die ersteren sind das, was Sie durch Ausführen von git commit committen würden; die zweiten und dritten sind das, was Sie durch Ausführen von git add vor dem Ausführen von git commit committen könnten.

OPTIONEN

-s
--short

Gibt die Ausgabe im Kurzformat aus.

-b
--branch

Zeigt den Branch und die Tracking-Infos auch im Kurzformat an.

--show-stash

Zeigt die Anzahl der aktuell gespeicherten Elemente an.

--porcelain[=<version>]

Gibt die Ausgabe in einem leicht zu analysierenden Format für Skripte aus. Dies ähnelt der Kurzform, bleibt aber über Git-Versionen und Benutzereinstellungen hinweg stabil. Details siehe unten.

Der Versionsparameter wird verwendet, um die Formatversion anzugeben. Dies ist optional und standardmäßig auf das ursprüngliche Format v1 eingestellt.

--long

Gibt die Ausgabe im Langformat aus. Dies ist die Standardeinstellung.

-v
--verbose

Zusätzlich zu den Namen der geänderten Dateien werden auch die Textänderungen angezeigt, die für den Commit vorbereitet sind (d. h. wie die Ausgabe von git diff --cached). Wenn -v zweimal angegeben wird, werden auch die Änderungen im Arbeitsverzeichnis angezeigt, die noch nicht vorbereitet wurden (d. h. wie die Ausgabe von git diff).

-u[<mode>]
--untracked-files[=<mode>]

Zeigt nicht verfolgte Dateien an.

Der Modusparameter wird verwendet, um die Behandlung von nicht verfolgten Dateien anzugeben. Er ist optional: Er standardmäßig auf all und muss, wenn angegeben, an die Option angehängt werden (z. B. -uno, aber nicht -u no).

Die möglichen Optionen sind

  • no - Zeigt keine nicht verfolgten Dateien an.

  • normal - Zeigt nicht verfolgte Dateien und Verzeichnisse an.

  • all - Zeigt auch einzelne Dateien in nicht verfolgten Verzeichnissen an.

Wenn die Option -u nicht verwendet wird, werden nicht verfolgte Dateien und Verzeichnisse angezeigt (d. h. dasselbe wie die Angabe von normal), um zu vermeiden, dass neue Dateien vergessen werden. Da die Suche nach nicht verfolgten Dateien im Dateisystem zusätzlichen Aufwand bedeutet, kann dieser Modus in einem großen Arbeitsverzeichnis einige Zeit in Anspruch nehmen. Erwägen Sie die Aktivierung des Cache für nicht verfolgte Dateien und die Aufteilung des Indexes, falls unterstützt (siehe git update-index --untracked-cache und git update-index --split-index). Andernfalls können Sie no verwenden, damit git status schneller zurückkehrt, ohne nicht verfolgte Dateien anzuzeigen. Alle üblichen Schreibweisen für den booleschen Wert true werden als normal und false als no interpretiert.

Die Standardeinstellung kann mit der Konfigurationsvariable status.showUntrackedFiles geändert werden, die in git-config[1] dokumentiert ist.

--ignore-submodules[=<when>]

Ignoriert Änderungen an Submodulen bei der Suche nach Änderungen. <when> kann entweder "none", "untracked", "dirty" oder "all" sein, was der Standard ist. Die Verwendung von "none" betrachtet das Submodul als modifiziert, wenn es nicht verfolgte oder modifizierte Dateien enthält oder sein HEAD vom im Superprojekt aufgezeichneten Commit abweicht, und kann verwendet werden, um alle Einstellungen der ignore-Option in git-config[1] oder gitmodules[5] zu überschreiben. Wenn "untracked" verwendet wird, werden Submodule nicht als schmutzig betrachtet, wenn sie nur nicht verfolgten Inhalt enthalten (sie werden jedoch immer noch auf modifizierten Inhalt gescannt). Die Verwendung von "dirty" ignoriert alle Änderungen am Arbeitsbaum von Submodulen, nur Änderungen an den im Superprojekt gespeicherten Commits werden angezeigt (dies war das Verhalten vor 1.7.0). Die Verwendung von "all" blendet alle Änderungen an Submodulen aus (und unterdrückt die Ausgabe von Submodulzusammenfassungen, wenn die Konfigurationsoption status.submoduleSummary gesetzt ist).

--ignored[=<mode>]

Zeigt auch ignorierte Dateien an.

Der Modusparameter wird verwendet, um die Behandlung von ignorierten Dateien anzugeben. Er ist optional: Er standardmäßig auf traditional.

Die möglichen Optionen sind

  • traditional - Zeigt ignorierte Dateien und Verzeichnisse an, es sei denn, --untracked-files=all wird angegeben, in welchem Fall einzelne Dateien in ignorierten Verzeichnissen angezeigt werden.

  • no - Zeigt keine ignorierten Dateien an.

  • matching - Zeigt ignorierte Dateien und Verzeichnisse an, die einem Ignore-Muster entsprechen.

Wenn der Modus matching angegeben ist, werden Pfade angezeigt, die explizit einem Ignore-Muster entsprechen. Wenn ein Verzeichnis einem Ignore-Muster entspricht, wird es angezeigt, aber nicht die darin enthaltenen Pfade. Wenn ein Verzeichnis keinem Ignore-Muster entspricht, aber alle Inhalte ignoriert werden, wird das Verzeichnis nicht angezeigt, aber alle Inhalte werden angezeigt.

-z

Beendet Einträge mit NUL anstelle von LF. Dies impliziert das Ausgabeformat --porcelain=v1, wenn kein anderes Format angegeben ist.

--column[=<options>]
--no-column

Zeigt nicht verfolgte Dateien in Spalten an. Siehe die Konfigurationsvariable column.status für die Optionssyntax. --column und --no-column ohne Optionen sind äquivalent zu always bzw. never.

--ahead-behind
--no-ahead-behind

Zeigt oder blendet detaillierte Ahead/Behind-Zählungen für den Branch relativ zu seinem Upstream-Branch ein/aus. Standard ist true.

--renames
--no-renames

Schaltet die Erkennung von Umbenennungen unabhängig von der Benutzereinstellung ein/aus. Siehe auch git-diff[1] --no-renames.

--find-renames[=<n>]

Schaltet die Erkennung von Umbenennungen ein, optional mit Angabe des Ähnlichkeitsschwellenwerts. Siehe auch git-diff[1] --find-renames.

<pathspec>…​

Siehe den Eintrag pathspec in gitglossary[7].

AUSGABE

Die Ausgabe dieses Befehls ist als Vorlage für Commit-Kommentare gedacht. Das Standard-Langformat ist auf Lesbarkeit, Ausführlichkeit und Beschreibung ausgelegt. Inhalt und Format können jederzeit geändert werden.

Die in der Ausgabe genannten Pfade sind, im Gegensatz zu vielen anderen Git-Befehlen, relativ zum aktuellen Verzeichnis, wenn Sie sich in einem Unterverzeichnis befinden (dies geschieht absichtlich, um das Kopieren und Einfügen zu erleichtern). Siehe die Konfigurationsoption status.relativePaths unten.

Kurzformat

Im Kurzformat wird der Status jedes Pfades als eine der folgenden Formen angezeigt

XY PATH
XY ORIG_PATH -> PATH

wobei ORIG_PATH der Ort ist, von dem die umbenannten/kopierten Inhalte stammen. ORIG_PATH wird nur angezeigt, wenn der Eintrag umbenannt oder kopiert wurde. XY ist ein zweistelliger Statuscode.

Die Felder (einschließlich der ->) sind durch ein einzelnes Leerzeichen voneinander getrennt. Wenn ein Dateiname Leerzeichen oder andere nicht druckbare Zeichen enthält, wird dieses Feld in der Art eines C-String-Literals zitiert: umgeben von ASCII-Anführungszeichen (34) und mit internen Sonderzeichen Backslash-eskapiert.

Es gibt drei verschiedene Arten von Zuständen, die mit diesem Format angezeigt werden, und jede verwendet die XY-Syntax unterschiedlich

  • Wenn ein Merge stattfindet und der Merge erfolgreich war, oder außerhalb einer Merge-Situation, zeigt X den Status des Indexes und Y den Status des Arbeitsverzeichnisses an.

  • Wenn ein Merge-Konflikt aufgetreten ist und noch nicht gelöst wurde, zeigen X und Y den Zustand an, der von jedem Kopf des Merges eingeführt wurde, relativ zum gemeinsamen Vorfahren. Diese Pfade werden als unmerged bezeichnet.

  • Wenn ein Pfad nicht verfolgt wird, sind X und Y immer gleich, da sie dem Index unbekannt sind. ?? wird für nicht verfolgte Pfade verwendet. Ignorierte Dateien werden nicht aufgelistet, es sei denn, --ignored wird verwendet; wenn ja, werden ignorierte Dateien durch !! gekennzeichnet.

Beachten Sie, dass der Begriff merge hier auch Rebases mit der Standardstrategie --merge, Cherry-Picks und alles andere, das die Merge-Maschinerie verwendet, einschließt.

In der folgenden Tabelle werden diese drei Klassen in separaten Abschnitten dargestellt, und diese Zeichen werden für die Felder X und Y für die ersten beiden Abschnitte, die verfolgte Pfade anzeigen, verwendet

  • ' ' = unverändert

  • M = geändert

  • T = Dateityp geändert (normale Datei, symbolischer Link oder Submodul)

  • A = hinzugefügt

  • D = gelöscht

  • R = umbenannt

  • C = kopiert (wenn die Konfigurationsoption status.renames auf "copies" gesetzt ist)

  • U = aktualisiert, aber nicht zusammengeführt

X          Y     Meaning
-------------------------------------------------
	 [AMD]   not updated
M        [ MTD]  updated in index
T        [ MTD]  type changed in index
A        [ MTD]  added to index
D                deleted from index
R        [ MTD]  renamed in index
C        [ MTD]  copied in index
[MTARC]          index and work tree matches
[ MTARC]    M    work tree changed since index
[ MTARC]    T    type changed in work tree since index
[ MTARC]    D    deleted in work tree
	    R    renamed in work tree
	    C    copied in work tree
-------------------------------------------------
D           D    unmerged, both deleted
A           U    unmerged, added by us
U           D    unmerged, deleted by them
U           A    unmerged, added by them
D           U    unmerged, deleted by us
A           A    unmerged, both added
U           U    unmerged, both modified
-------------------------------------------------
?           ?    untracked
!           !    ignored
-------------------------------------------------

Submodule haben mehr Status und melden stattdessen

  • M = das Submodul hat einen anderen HEAD als im Index aufgezeichnet

  • m = das Submodul hat geänderten Inhalt

  • ? = das Submodul hat nicht verfolgte Dateien

Dies liegt daran, dass geänderter Inhalt oder nicht verfolgte Dateien in einem Submodul nicht über git add im Superprojekt hinzugefügt werden können, um einen Commit vorzubereiten.

m und ? werden rekursiv angewendet. Wenn zum Beispiel ein verschachteltes Submodul in einem Submodul eine nicht verfolgte Datei enthält, wird dies ebenfalls als ? gemeldet.

Wenn -b verwendet wird, geht der Kurzform-Status einer Zeile voraus

## branchname tracking info

Porcelain-Format Version 1

Das Porcelain-Format Version 1 ähnelt dem Kurzformat, ist aber garantiert nicht abwärtskompatibel zwischen Git-Versionen oder basierend auf Benutzereinstellungen veränderbar. Dies macht es ideal für die Verarbeitung durch Skripte. Die Beschreibung des Kurzformats oben beschreibt auch das Porcelain-Format, mit einigen Ausnahmen

  1. Die Benutzereinstellung color.status wird nicht beachtet; die Farbe ist immer aus.

  2. Die Benutzereinstellung status.relativePaths wird nicht beachtet; die angezeigten Pfade sind immer relativ zum Repository-Root.

Es gibt auch ein alternatives -z-Format, das für maschinelle Verarbeitung empfohlen wird. In diesem Format ist das Statusfeld dasselbe, aber einige andere Dinge ändern sich. Erstens wird das -> aus Umbenennungseinträgen weggelassen und die Feldreihenfolge wird umgekehrt (z. B. from -> to wird zu to from). Zweitens folgt ein NUL (ASCII 0) auf jedem Dateinamen und ersetzt das Leerzeichen als Feldtrenner und den abschließenden Zeilenumbruch (aber ein Leerzeichen trennt immer noch das Statusfeld vom ersten Dateinamen). Drittens werden Dateinamen mit Sonderzeichen nicht speziell formatiert; es erfolgt keine Anführungszeichensetzung oder Backslash-Escapierung.

Alle Submoduländerungen werden als geändert M anstelle von m oder einem einzelnen ? gemeldet.

Porcelain-Format Version 2

Das Format Version 2 fügt detailliertere Informationen über den Zustand des Arbeitsverzeichnisses und der geänderten Elemente hinzu. Version 2 definiert auch einen erweiterbaren Satz von leicht zu analysierenden optionalen Headern.

Headerzeilen beginnen mit "#" und werden als Reaktion auf bestimmte Befehlszeilenargumente hinzugefügt. Parser sollten Header ignorieren, die sie nicht erkennen.

Branch-Header

Wenn --branch angegeben ist, werden eine Reihe von Headerzeilen mit Informationen über den aktuellen Branch gedruckt.

Line                                     Notes
------------------------------------------------------------
# branch.oid <commit> | (initial)        Current commit.
# branch.head <branch> | (detached)      Current branch.
# branch.upstream <upstream-branch>      If upstream is set.
# branch.ab +<ahead> -<behind>           If upstream is set and
					 the commit is present.
------------------------------------------------------------

Stash-Informationen

Wenn --show-stash angegeben ist, wird eine Zeile gedruckt, die die Anzahl der Stash-Einträge anzeigt, wenn sie nicht null ist

# stash <N>

Geänderte verfolgte Einträge

Nach den Headern wird eine Reihe von Zeilen für verfolgte Einträge gedruckt. Eines von drei verschiedenen Zeilenformaten kann verwendet werden, um einen Eintrag zu beschreiben, abhängig von der Art der Änderung. Verfolgte Einträge werden in undefinierter Reihenfolge gedruckt; Parser sollten eine Mischung der 3 Zeilentypen in beliebiger Reihenfolge zulassen.

Gewöhnliche geänderte Einträge haben das folgende Format

1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>

Umbenannte oder kopierte Einträge haben das folgende Format

2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
Field       Meaning
--------------------------------------------------------
<XY>        A 2 character field containing the staged and
	    unstaged XY values described in the short format,
	    with unchanged indicated by a "." rather than
	    a space.
<sub>       A 4 character field describing the submodule state.
	    "N..." when the entry is not a submodule.
	    "S<c><m><u>" when the entry is a submodule.
	    <c> is "C" if the commit changed; otherwise ".".
	    <m> is "M" if it has tracked changes; otherwise ".".
	    <u> is "U" if there are untracked changes; otherwise ".".
<mH>        The octal file mode in HEAD.
<mI>        The octal file mode in the index.
<mW>        The octal file mode in the worktree.
<hH>        The object name in HEAD.
<hI>        The object name in the index.
<X><score>  The rename or copy score (denoting the percentage
	    of similarity between the source and target of the
	    move or copy). For example "R100" or "C75".
<path>      The pathname.  In a renamed/copied entry, this
	    is the target path.
<sep>       When the `-z` option is used, the 2 pathnames are separated
	    with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
	    byte separates them.
<origPath>  The pathname in the commit at HEAD or in the index.
	    This is only present in a renamed/copied entry, and
	    tells where the renamed/copied contents came from.
--------------------------------------------------------

Nicht zusammengeführte Einträge haben das folgende Format; das erste Zeichen ist ein "u", um sie von gewöhnlichen geänderten Einträgen zu unterscheiden.

u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
Field       Meaning
--------------------------------------------------------
<XY>        A 2 character field describing the conflict type
	    as described in the short format.
<sub>       A 4 character field describing the submodule state
	    as described above.
<m1>        The octal file mode in stage 1.
<m2>        The octal file mode in stage 2.
<m3>        The octal file mode in stage 3.
<mW>        The octal file mode in the worktree.
<h1>        The object name in stage 1.
<h2>        The object name in stage 2.
<h3>        The object name in stage 3.
<path>      The pathname.
--------------------------------------------------------

Andere Elemente

Nach den verfolgten Einträgen (und falls angefordert) wird eine Reihe von Zeilen für nicht verfolgte und dann ignorierte Elemente im Arbeitsverzeichnis gedruckt.

Nicht verfolgte Elemente haben das folgende Format

? <path>

Ignorierte Elemente haben das folgende Format

! <path>

Hinweise zum Pfadnamenformat und -z

Wenn die Option -z angegeben ist, werden Pfadnamen unverändert und ohne Anführungszeichen gedruckt und Zeilen werden mit einem NUL (ASCII 0x00) Byte beendet.

Ohne die Option -z werden Pfadnamen mit "ungewöhnlichen" Zeichen wie für die Konfigurationsvariable core.quotePath erklärt zitiert (siehe git-config[1]).

KONFIGURATION

Der Befehl berücksichtigt die Konfigurationsvariablen color.status (oder status.color — sie bedeuten dasselbe und letztere wird aus Gründen der Abwärtskompatibilität beibehalten) und color.status.<slot>, um seine Ausgabe zu farbig zu gestalten.

Wenn die Konfigurationsvariable status.relativePaths auf false gesetzt ist, dann sind alle angezeigten Pfade relativ zum Repository-Root und nicht zum aktuellen Verzeichnis.

Wenn status.submoduleSummary auf eine von Null verschiedene Zahl oder true gesetzt ist (identisch mit -1 oder einer unbegrenzten Anzahl), wird die Submodulübersicht für das Langformat aktiviert und eine Zusammenfassung der Commits für geänderte Submodule angezeigt (siehe --summary-limit Option von git-submodule[1]). Bitte beachten Sie, dass die Zusammenfassungsausgabe des Statusbefehls für alle Submodule unterdrückt wird, wenn diff.ignoreSubmodules auf all gesetzt ist, oder nur für die Submodule, bei denen submodule.<name>.ignore=all gilt. Um die Zusammenfassung auch für ignorierte Submodule anzuzeigen, können Sie entweder die Kommandozeilenoption --ignore-submodules=dirty verwenden oder den Befehl git submodule summary, der eine ähnliche Ausgabe anzeigt, aber diese Einstellungen nicht berücksichtigt.

HINTERGRUND-AKTUALISIERUNG

Standardmäßig aktualisiert git status automatisch den Index, aktualisiert die zwischengespeicherten Statusinformationen aus dem Arbeitsverzeichnis und schreibt das Ergebnis. Das Schreiben des aktualisierten Index ist eine Optimierung, die nicht unbedingt erforderlich ist (status berechnet die Werte selbst, aber das Schreiben ist nur dazu gedacht, nachfolgenden Programmen zu ersparen, unsere Berechnung zu wiederholen). Wenn status im Hintergrund ausgeführt wird, kann die während des Schreibens gehaltene Sperre mit anderen gleichzeitigen Prozessen kollidieren, was zu deren Fehlschlag führt. Skripte, die status im Hintergrund ausführen, sollten die Verwendung von git --no-optional-locks status in Betracht ziehen (siehe git[1] für Details).

NICHT VERFOLGTE DATEIEN UND LEISTUNG

git status kann in großen Arbeitsverzeichnissen sehr langsam sein, wenn es nach nicht verfolgten Dateien und Verzeichnissen suchen muss. Es gibt viele verfügbare Konfigurationsoptionen, um dies zu beschleunigen, entweder durch Vermeidung der Arbeit oder durch Nutzung zwischengespeicherter Ergebnisse aus früheren Git-Befehlen. Es gibt keine einzelne optimale Einstellung für alle. Wir listen eine Zusammenfassung der relevanten Optionen auf, um Ihnen zu helfen, aber bevor Sie in die Liste einsteigen, möchten Sie vielleicht git status erneut ausführen, da Ihre Konfiguration möglicherweise bereits git status Ergebnisse zwischenspeichert, sodass es bei nachfolgenden Ausführungen schneller sein könnte.

  • Die Option --untracked-files=no oder die Konfiguration status.showUntrackedFiles=no (siehe oben für beide): gibt an, dass git status keine nicht verfolgten Dateien melden soll. Dies ist die schnellste Option. git status listet die nicht verfolgten Dateien nicht auf, daher müssen Sie vorsichtig sein, sich daran zu erinnern, ob Sie neue Dateien erstellen und sie manuell git adden.

  • advice.statusUoption=false (siehe git-config[1]): das Setzen dieser Variablen auf false deaktiviert die Warnmeldung, die gegeben wird, wenn die Auflistung nicht verfolgter Dateien länger als 2 Sekunden dauert. In einem großen Projekt kann dies länger dauern, und der Benutzer hat den Kompromiss möglicherweise bereits akzeptiert (z. B. ist die Verwendung von "-uno" für den Benutzer möglicherweise keine akzeptable Option), in welchem Fall es keinen Sinn macht, die Warnmeldung auszugeben, und in einem solchen Fall ist die Deaktivierung der Warnung möglicherweise am besten.

  • core.untrackedCache=true (siehe git-update-index[1]): aktiviert die Funktion des Caches für nicht verfolgte Dateien und durchsucht nur Verzeichnisse, die seit dem vorherigen git status-Befehl geändert wurden. Git merkt sich die Menge der nicht verfolgten Dateien innerhalb jedes Verzeichnisses und geht davon aus, dass, wenn ein Verzeichnis nicht geändert wurde, sich auch die Menge der darin enthaltenen nicht verfolgten Dateien nicht geändert hat. Dies ist viel schneller als die Auflistung des Inhalts jedes Verzeichnisses, aber immer noch nicht ohne Kosten, da Git immer noch nach der Menge der geänderten Verzeichnisse suchen muss. Der Cache für nicht verfolgte Dateien wird in der Datei .git/index gespeichert. Die reduzierte Kosten für die Suche nach nicht verfolgten Dateien werden durch die erhöhte Größe des Index und die Kosten für dessen Aktualisierung leicht aufgewogen. Diese reduzierte Suchzeit ist die zusätzlichen Größe normalerweise wert.

  • core.untrackedCache=true und core.fsmonitor=true oder core.fsmonitor=<hook-command-pathname> (siehe git-update-index[1]): aktiviert sowohl den Cache für nicht verfolgte Dateien als auch die FSMonitor-Funktionen und durchsucht nur Verzeichnisse, die seit dem vorherigen git status-Befehl geändert wurden. Dies ist schneller als nur der Cache für nicht verfolgte Dateien, da Git auch vermeiden kann, nach geänderten Verzeichnissen zu suchen. Git muss nur die genaue Menge der kürzlich geänderten Verzeichnisse auflisten. Obwohl die FSMonitor-Funktion ohne den Cache für nicht verfolgte Dateien aktiviert werden kann, sind die Vorteile in diesem Fall erheblich reduziert.

Beachten Sie, dass es nach der Aktivierung der Funktionen für den Cache für nicht verfolgte Dateien und/oder FSMonitor einige git status-Befehle dauern kann, bis die verschiedenen Caches aufgewärmt sind, bevor Sie verbesserte Befehlszeiten sehen. Dies ist normal.

SIEHE AUCH

gitignore[5]

GIT

Teil der git[1] Suite