Der vollständige SHA-1 Objektname (40-stellige hexadezimale Zeichenkette) oder ein führendes Teilzeichen, das im Repository eindeutig ist. Z. B. dae86e1950b1277e545cee180551750029cfe735 und dae86e bezeichnen beide das gleiche Commit-Objekt, wenn kein anderes Objekt in Ihrem Repository existiert, dessen Objektname mit dae86e beginnt.

Ausgabe von git describe; d. h. ein nächstgelegener Tag, optional gefolgt von einem Bindestrich und einer Anzahl von Commits, gefolgt von einem Bindestrich, einem g und einem abgekürzten Objektnamen.

Ein symbolischer Ref-Name. Z. B. bedeutet master typischerweise das Commit-Objekt, auf das von refs/heads/master verwiesen wird. Wenn Sie sowohl heads/master als auch tags/master haben, können Sie explizit heads/master sagen, um Git mitzuteilen, welches Sie meinen. Bei Mehrdeutigkeit wird ein <refname> durch den ersten Treffer in den folgenden Regeln disambiguiert

@ allein ist eine Abkürzung für HEAD.

Ein Ref, gefolgt vom Suffix @ mit einer Datumsangabe in geschweiften Klammern (z. B. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} oder {1979-02-26 18:30:00}) bezeichnet den Wert des Refs zu einem früheren Zeitpunkt. Dieses Suffix kann nur unmittelbar nach einem Ref-Namen verwendet werden und der Ref muss ein vorhandenes Log haben ($GIT_DIR/logs/<ref>). Beachten Sie, dass dies den Zustand Ihres lokalen Refs zu einer bestimmten Zeit nachschlägt; z. B. was letzte Woche in Ihrem lokalen master Branch war. Wenn Sie Commits zu bestimmten Zeiten betrachten möchten, siehe --since und --until.

Ein Ref, gefolgt vom Suffix @ mit einer ordinalen Angabe in geschweiften Klammern (z. B. {1}, {15}) bezeichnet den n-ten vorherigen Wert dieses Refs. Zum Beispiel ist master@{1} der unmittelbar vorherige Wert von master, während master@{5} der 5. vorherige Wert von master ist. Dieses Suffix kann nur unmittelbar nach einem Ref-Namen verwendet werden und der Ref muss ein vorhandenes Log haben ($GIT_DIR/logs/<refname>).

Sie können die @-Konstruktion mit einem leeren Ref-Teil verwenden, um auf einen Reflog-Eintrag des aktuellen Branches zuzugreifen. Zum Beispiel, wenn Sie sich auf dem Branch blabla befinden, bedeutet @{1} das Gleiche wie blabla@{1}.

Die Konstruktion @{-<n>} bezeichnet den <n>-ten Branch/Commit, der vor dem aktuellen ausgecheckt wurde.

Ein Branch B kann so konfiguriert werden, dass er auf einem Branch X (konfiguriert mit branch.<name>.merge) auf einem Remote R (konfiguriert mit branch.<name>.remote) aufbaut. B@{u} bezeichnet den Remote-Tracking-Branch für den Branch X, genommen von Remote R, typischerweise zu finden unter refs/remotes/R/X.

Das Suffix @{push} gibt den Branch an, "wohin wir pushen würden", wenn git push ausgeführt würde, während branchname ausgecheckt war (oder der aktuelle HEAD, wenn kein branchname angegeben ist). Wie bei @{upstream} geben wir den Remote-Tracking-Branch an, der diesem Branch auf dem Remote entspricht.

$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

Ein Suffix ^ zu einem Revisionsparameter bedeutet den ersten Elternteil dieses Commit-Objekts. ^<n> bedeutet den <n>-ten Elternteil (d. h. <rev>^ ist äquivalent zu <rev>^1). Als Sonderregel bedeutet <rev>^0 den Commit selbst und wird verwendet, wenn <rev> der Objektname eines Tag-Objekts ist, das auf ein Commit-Objekt verweist.

Ein Suffix ~ zu einem Revisionsparameter bedeutet den ersten Elternteil dieses Commit-Objekts. Ein Suffix ~<n> zu einem Revisionsparameter bedeutet das Commit-Objekt, das die <n>-te Generation des benannten Commit-Objekts als Vorfahre ist, nur den ersten Elternteilen folgend. D. h. <rev>~3 ist äquivalent zu <rev>^^^, was wiederum äquivalent ist zu <rev>^1^1^1. Siehe unten für eine Illustration der Verwendung dieser Form.

Ein Suffix ^, gefolgt von einem Objekttypnamen in geschweiften Klammern, bedeutet, das Objekt bei <rev> rekursiv zu dereferenzieren, bis ein Objekt vom Typ <type> gefunden wird oder das Objekt nicht mehr dereferenziert werden kann (in diesem Fall fehlschlagen). Zum Beispiel, wenn <rev> ein Commit-ish ist, beschreibt <rev>^{commit} das entsprechende Commit-Objekt. Ebenso, wenn <rev> ein Tree-ish ist, beschreibt <rev>^{tree} das entsprechende Tree-Objekt. <rev>^0 ist eine Kurzform für <rev>^{commit}.

Ein Suffix ^, gefolgt von einem leeren Klammerpaar, bedeutet, dass das Objekt ein Tag sein könnte, und dereferenziert den Tag rekursiv, bis ein Nicht-Tag-Objekt gefunden wird.

Ein Suffix ^ zu einem Revisionsparameter, gefolgt von einem Klammerpaar, das einen Text mit einem Schrägstrich enthält, ist dasselbe wie die :/fix nasty bug Syntax unten, außer dass er den jüngsten übereinstimmenden Commit zurückgibt, der von <rev> vor ^ erreichbar ist.

Ein Doppelpunkt, gefolgt von einem Schrägstrich, gefolgt von einem Text, benennt einen Commit, dessen Commit-Nachricht dem angegebenen regulären Ausdruck entspricht. Dieser Name gibt den jüngsten übereinstimmenden Commit zurück, der von jedem Ref, einschließlich HEAD, erreichbar ist. Der reguläre Ausdruck kann jeden Teil der Commit-Nachricht abgleichen. Um Nachrichten zu finden, die mit einer Zeichenkette beginnen, kann man z. B. :/^foo verwenden. Die spezielle Sequenz :/! ist für Modifikatoren dessen, was abgeglichen wird, reserviert. :/!-foo führt einen negativen Abgleich durch, während :/!!foo ein literales ! gefolgt von foo abgleicht. Jede andere Sequenz, die mit :/! beginnt, ist derzeit reserviert. Abhängig vom gegebenen Text erfordern die Wortaufteilungsregeln der Shell möglicherweise zusätzliche Anführungszeichen.

Ein Suffix :, gefolgt von einem Pfad, benennt den Blob oder Tree am angegebenen Pfad im Tree-ish-Objekt, das durch den Teil vor dem Doppelpunkt benannt wird. Ein Pfad, der mit ./ oder ../ beginnt, ist relativ zum aktuellen Arbeitsverzeichnis. Der angegebene Pfad wird in einen Pfad relativ zum Stammverzeichnis des Arbeitsbaums konvertiert. Dies ist am nützlichsten, um einen Blob oder Tree von einem Commit oder Tree anzusprechen, der die gleiche Baumstruktur wie der Arbeitsbaum hat.

Ein Doppelpunkt, optional gefolgt von einer Stufennummer (0 bis 3) und einem Doppelpunkt, gefolgt von einem Pfad, benennt ein Blob-Objekt im Index am angegebenen Pfad. Eine fehlende Stufennummer (und der folgende Doppelpunkt) benennt einen Eintrag der Stufe 0. Während eines Merges ist Stufe 1 der gemeinsame Vorfahre, Stufe 2 ist die Version des Zielbranches (typischerweise der aktuelle Branch), und Stufe 3 ist die Version des Branches, der gemerged wird.

Schließt Commits ein, die von <rev> erreichbar sind (d. h. <rev> und seine Vorfahren).

Schließt Commits aus, die von <rev> erreichbar sind (d. h. <rev> und seine Vorfahren).

Schließt Commits ein, die von <rev2> erreichbar sind, schließt aber diejenigen aus, die von <rev1> erreichbar sind. Wenn entweder <rev1> oder <rev2> weggelassen wird, wird standardmäßig HEAD verwendet.

Schließt Commits ein, die von entweder <rev1> oder <rev2> erreichbar sind, schließt aber diejenigen aus, die von beiden erreichbar sind. Wenn entweder <rev1> oder <rev2> weggelassen wird, wird standardmäßig HEAD verwendet.

Ein Suffix ^ gefolgt von einem At-Zeichen ist dasselbe wie das Auflisten aller Eltern von <rev> (bedeutet, schließt alles ein, was von seinen Eltern erreichbar ist, aber nicht den Commit selbst).

Ein Suffix ^ gefolgt von einem Ausrufezeichen ist dasselbe wie die Angabe des Commits <rev> und aller seiner Eltern, die mit ^ präfigiert sind, um sie (und ihre Vorfahren) auszuschließen.

Äquivalent zu <rev>^<n>..<rev>, mit <n> = 1, wenn nicht gegeben.