English ▾ Themen ▾ Neueste Version ▾ git zuletzt aktualisiert in 2.52.0

NAME

git - der dumme Inhalts-Tracker

SYNOPSIS

git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
    [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
    [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
    [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
    [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
    <command> [<args>]

BESCHREIBUNG

Git ist ein schnelles, skalierbares, verteiltes Revisionskontrollsystem mit einem ungewöhnlich umfangreichen Befehlssatz, der sowohl hochrangige Operationen als auch vollen Zugriff auf interne Funktionen bietet.

Siehe gittutorial[7] für den Einstieg, dann siehe giteveryday[7] für eine nützliche Mindestmenge an Befehlen. Das Git User's Manual bietet eine ausführlichere Einführung.

Nachdem Sie die grundlegenden Konzepte gemeistert haben, können Sie auf diese Seite zurückkehren, um zu erfahren, welche Befehle Git bietet. Mehr über einzelne Git-Befehle erfahren Sie mit "git help command". Die Handbuchseite gitcli[7] gibt Ihnen einen Überblick über die Syntax der Befehlszeilenbefehle.

Eine formatierte und hyperverlinkte Kopie der neuesten Git-Dokumentation kann unter https://git.github.io/htmldocs/git.html oder https://git-scm.de/docs eingesehen werden.

OPTIONEN

-v
--version

Gibt die Git-Suite-Version aus, von der das Programm git stammt.

Diese Option wird intern in git version ... umgewandelt und akzeptiert dieselben Optionen wie der Befehl git-version[1]. Wenn auch --help angegeben wird, hat dies Vorrang vor --version.

-h
--help

Gibt die Syntax und eine Liste der am häufigsten verwendeten Befehle aus. Wenn die Option --all oder -a angegeben wird, werden alle verfügbaren Befehle ausgegeben. Wenn ein Git-Befehl benannt wird, ruft diese Option die Handbuchseite für diesen Befehl auf.

Weitere Optionen sind verfügbar, um die Anzeige der Handbuchseite zu steuern. Informationen dazu finden Sie unter git-help[1], da git --help ... intern in git help ... umgewandelt wird.

-C <Pfad>

Führen Sie aus, als ob git in <Pfad> statt im aktuellen Arbeitsverzeichnis gestartet worden wäre. Wenn mehrere -C Optionen angegeben werden, wird jede nachfolgende nicht-absolute -C <Pfad> relativ zur vorherigen -C <Pfad> interpretiert. Wenn <Pfad> vorhanden, aber leer ist, z. B. -C "", dann bleibt das aktuelle Arbeitsverzeichnis unverändert.

Diese Option beeinflusst Optionen, die Pfadnamen erwarten, wie z. B. --git-dir und --work-tree, da deren Interpretation der Pfadnamen relativ zum Arbeitsverzeichnis erfolgt, das durch die Option -C verursacht wurde. Zum Beispiel sind die folgenden Aufrufe äquivalent

git --git-dir=a.git --work-tree=b -C c status
git --git-dir=c/a.git --work-tree=c/b status
-c <Name>=<Wert>

Übergibt einen Konfigurationsparameter an den Befehl. Der angegebene Wert überschreibt Werte aus Konfigurationsdateien. Der <Name> wird im selben Format erwartet, wie er von git config aufgeführt wird (Unterkeys getrennt durch Punkte).

Beachten Sie, dass das Weglassen des = in git -c foo.bar ... zulässig ist und foo.bar auf den booleschen Wert true setzt (ähnlich wie [foo]bar in einer Konfigurationsdatei). Das Einbeziehen des Gleichheitszeichens mit einem leeren Wert (wie git -c foo.bar= ...) setzt foo.bar auf den leeren String, den git config --type=bool in false konvertiert.

--config-env=<Name>=<Umgebungsvariable>

Ähnlich wie -c <Name>=<Wert>, weist der Konfigurationsvariable <Name> einen Wert zu, wobei <Umgebungsvariable> der Name einer Umgebungsvariablen ist, aus der der Wert abgerufen werden soll. Im Gegensatz zu -c gibt es keine Kurzform zum direkten Setzen des Wertes auf einen leeren String; stattdessen muss die Umgebungsvariable selbst auf den leeren String gesetzt werden. Es ist ein Fehler, wenn die <Umgebungsvariable> in der Umgebung nicht existiert. <Umgebungsvariable> darf kein Gleichheitszeichen enthalten, um Mehrdeutigkeit zu vermeiden, falls <Name> eines enthält.

Dies ist nützlich für Fälle, in denen Sie flüchtige Konfigurationsoptionen an git übergeben möchten, dies aber auf Betriebssystemen tun, auf denen andere Prozesse Ihre Kommandozeile (z. B. /proc/self/cmdline) lesen könnten, aber nicht Ihre Umgebung (z. B. /proc/self/environ). Dieses Verhalten ist unter Linux Standard, aber möglicherweise nicht auf Ihrem System.

Beachten Sie, dass dies die Sicherheit für Variablen wie http.extraHeader erhöhen kann, bei denen die sensiblen Informationen Teil des Wertes sind, aber nicht z. B. für url.<base>.insteadOf, wo die sensiblen Informationen Teil des Schlüssels sein können.

--exec-path[=<Pfad>]

Pfad zu den Kern-Git-Programmen, wo immer sie installiert sind. Dies kann auch durch Setzen der Umgebungsvariable GIT_EXEC_PATH gesteuert werden. Wenn kein Pfad angegeben wird, gibt git die aktuelle Einstellung aus und beendet sich dann.

--html-path

Gibt den Pfad aus, ohne abschließenden Schrägstrich, an dem die HTML-Dokumentation von Git installiert ist, und beendet sich.

--man-path

Gibt den Manpath (siehe man(1)) für die Manpages dieser Git-Version aus und beendet sich.

--info-path

Gibt den Pfad aus, an dem die Info-Dateien zur Dokumentation dieser Git-Version installiert sind, und beendet sich.

-p
--paginate

Leitet die gesamte Ausgabe in less (oder, wenn gesetzt, $PAGER) um, wenn die Standardausgabe ein Terminal ist. Dies überschreibt die Konfigurationsoptionen pager.<cmd> (siehe Abschnitt "Konfigurationsmechanismus" unten).

-P
--no-pager

Leitet die Git-Ausgabe nicht in einen Pager um.

--git-dir=<Pfad>

Legt den Pfad zum Repository (".git"-Verzeichnis) fest. Dies kann auch durch Setzen der Umgebungsvariable GIT_DIR gesteuert werden. Es kann ein absoluter Pfad oder ein relativer Pfad zum aktuellen Arbeitsverzeichnis sein.

Die Angabe des Speicherorts des ".git"-Verzeichnisses mit dieser Option (oder der Umgebungsvariable GIT_DIR) deaktiviert die Repository-Suche, die versucht, ein Verzeichnis mit einer ".git"-Unterverzeichnis zu finden (wodurch das Repository und die oberste Ebene des Arbeitsbaums entdeckt werden), und teilt Git mit, dass Sie sich auf der obersten Ebene des Arbeitsbaums befinden. Wenn Sie sich nicht im obersten Verzeichnis des Arbeitsbaums befinden, sollten Sie Git mit der Option --work-tree=<Pfad> (oder der Umgebungsvariable GIT_WORK_TREE) mitteilen, wo sich die oberste Ebene des Arbeitsbaums befindet.

Wenn Sie git einfach so ausführen möchten, als wäre es in <Pfad> gestartet worden, verwenden Sie git -C <Pfad>.

--work-tree=<Pfad>

Legt den Pfad zum Arbeitsbaum fest. Es kann ein absoluter Pfad oder ein Pfad relativ zum aktuellen Arbeitsverzeichnis sein. Dies kann auch durch Setzen der Umgebungsvariable GIT_WORK_TREE und der Konfigurationsvariable core.worktree gesteuert werden (siehe core.worktree in git-config[1] für eine detailliertere Diskussion).

--namespace=<Pfad>

Legt den Git-Namespace fest. Weitere Details finden Sie unter gitnamespaces[7]. Äquivalent zum Setzen der Umgebungsvariable GIT_NAMESPACE.

--bare

Behandelt das Repository als ein Bare-Repository. Wenn die Umgebungsvariable GIT_DIR nicht gesetzt ist, wird sie auf das aktuelle Arbeitsverzeichnis gesetzt.

--no-replace-objects

Verwendet keine Ersetzungsreferenzen, um Git-Objekte zu ersetzen. Dies ist äquivalent zum Exportieren der Umgebungsvariable GIT_NO_REPLACE_OBJECTS mit beliebigem Wert. Weitere Informationen finden Sie unter git-replace[1].

--no-lazy-fetch

Ruft fehlende Objekte nicht bei Bedarf vom Promisor-Remote ab. Nützlich zusammen mit git cat-file -e <Objekt>, um zu sehen, ob das Objekt lokal verfügbar ist. Dies ist äquivalent zum Setzen der Umgebungsvariable GIT_NO_LAZY_FETCH auf 1.

--no-optional-locks

Führt keine optionalen Operationen aus, die Sperren erfordern. Dies ist äquivalent zum Setzen von GIT_OPTIONAL_LOCKS auf 0.

--no-advice

Deaktiviert die Ausgabe aller Ratschläge.

--literal-pathspecs

Behandelt Pfadangaben wörtlich (d. h. kein Globbing, keine Pfadspec-Magie). Dies ist äquivalent zum Setzen der Umgebungsvariable GIT_LITERAL_PATHSPECS auf 1.

--glob-pathspecs

Fügt allen Pfadangaben "glob"-Magie hinzu. Dies ist äquivalent zum Setzen der Umgebungsvariable GIT_GLOB_PATHSPECS auf 1. Das Deaktivieren von Globbing für einzelne Pfadangaben kann mit der Pfadspec-Magie ":(literal)" erfolgen.

--noglob-pathspecs

Fügt allen Pfadangaben "literal"-Magie hinzu. Dies ist äquivalent zum Setzen der Umgebungsvariable GIT_NOGLOB_PATHSPECS auf 1. Das Aktivieren von Globbing für einzelne Pfadangaben kann mit der Pfadspec-Magie ":(glob)" erfolgen.

--icase-pathspecs

Fügt allen Pfadangaben "icase"-Magie hinzu. Dies ist äquivalent zum Setzen der Umgebungsvariable GIT_ICASE_PATHSPECS auf 1.

--list-cmds=<Gruppe>[,<Gruppe>…​]

Listet Befehle nach Gruppe auf. Dies ist eine interne/experimentelle Option und kann sich in Zukunft ändern oder entfernt werden. Unterstützte Gruppen sind: builtins, parseopt (eingebaute Befehle, die parse-options verwenden), deprecated (veraltete eingebaute Befehle), main (alle Befehle im libexec-Verzeichnis), others (alle anderen Befehle in $PATH mit dem Präfix git-), list-<kategorie> (siehe Kategorien in command-list.txt), nohelpers (Hilfsbefehle ausschließen), alias und config (Befehlsliste aus Konfigurationsvariable completion.commands abrufen).

--attr-source=<tree-ish>

Liest gitattributes aus <tree-ish> anstelle des Arbeitsbaums. Siehe gitattributes[5]. Dies ist äquivalent zum Setzen der Umgebungsvariable GIT_ATTR_SOURCE.

GIT BEFEHLE

Wir teilen Git in Befehle auf hoher Ebene ("Porcelain") und Befehle auf niedriger Ebene ("Plumbing") ein.

Befehle auf hoher Ebene (Porcelain)

Wir trennen die Porcelain-Befehle in die Hauptbefehle und einige ergänzende Benutzerhilfen.

Haupt-Porcelain-Befehle

git-add[1]

Fügt Datei-Inhalte zum Index hinzu

git-am[1]

Wendet eine Reihe von Patches aus einer Mailbox an

git-archive[1]

Erstellt ein Archiv von Dateien aus einem benannten Baum

git-backfill[1]

Lädt fehlende Objekte in einem Teilklon herunter

git-bisect[1]

Verwendet binäre Suche, um den Commit zu finden, der einen Fehler eingeführt hat

git-branch[1]

Listet, erstellt oder löscht Zweige

git-bundle[1]

Bewegt Objekte und Referenzen per Archiv

git-checkout[1]

Wechselt Zweige oder stellt Arbeitsbaumdateien wieder her

git-cherry-pick[1]

Wendet die Änderungen an, die durch einige vorhandene Commits eingeführt wurden

git-citool[1]

Grafische Alternative zu git-commit

git-clean[1]

Entfernt nicht verfolgte Dateien aus dem Arbeitsbaum

git-clone[1]

Klonen eines Repositorys in ein neues Verzeichnis

git-commit[1]

Zeichnet Änderungen im Repository auf

git-describe[1]

Gibt einem Objekt einen menschenlesbaren Namen basierend auf einer verfügbaren Referenz

git-diff[1]

Zeigt Änderungen zwischen Commits, Commit und Arbeitsbaum usw.

git-fetch[1]

Lädt Objekte und Referenzen aus einem anderen Repository herunter

git-format-patch[1]

Bereitet Patches für die E-Mail-Einreichung vor

git-gc[1]

Bereinigt unnötige Dateien und optimiert das lokale Repository

git-grep[1]

Gibt Zeilen aus, die einem Muster entsprechen

git-gui[1]

Eine portable grafische Benutzeroberfläche für Git

git-init[1]

Erstellt ein leeres Git-Repository oder initialisiert ein bestehendes neu

git-log[1]

Zeigt Commit-Logs an

git-maintenance[1]

Führt Aufgaben zur Optimierung von Git-Repository-Daten aus

git-merge[1]

Fügt zwei oder mehr Entwicklungsgeschichten zusammen

git-mv[1]

Verschiebt oder benennt eine Datei, ein Verzeichnis oder einen Symlink um

git-notes[1]

Fügt Notizen zu Objekten hinzu oder inspiziert sie

git-pull[1]

Holt von und integriert mit einem anderen Repository oder einem lokalen Zweig

git-push[1]

Aktualisiert Remote-Referenzen zusammen mit zugehörigen Objekten

git-range-diff[1]

Vergleicht zwei Commit-Bereiche (z. B. zwei Versionen eines Zweigs)

git-rebase[1]

Wendet Commits erneut auf eine andere Basis-Spitze an

git-reset[1]

Setzt den aktuellen HEAD auf den angegebenen Zustand zurück

git-restore[1]

Stellt Arbeitsbaumdateien wieder her

git-revert[1]

Macht einige bestehende Commits rückgängig

git-rm[1]

Entfernt Dateien aus dem Arbeitsbaum und dem Index

git-shortlog[1]

Fasst die Ausgabe von git log zusammen

git-show[1]

Zeigt verschiedene Arten von Objekten an

git-sparse-checkout[1]

Reduziert Ihren Arbeitsbaum auf eine Teilmenge von verfolgten Dateien

git-stash[1]

Lagert Änderungen in einem unsauberen Arbeitsverzeichnis aus

git-status[1]

Zeigt den Status des Arbeitsbaums an

git-submodule[1]

Initialisiert, aktualisiert oder inspiziert Untermodule

git-switch[1]

Wechselt Zweige

git-tag[1]

Erstellt, listet, löscht oder verifiziert Tags

git-worktree[1]

Verwaltet mehrere Arbeitsbäume

gitk[1]

Der Git-Repository-Browser

scalar[1]

Ein Werkzeug zur Verwaltung großer Git-Repositories

Ergänzende Befehle

Manipulatoren

git-config[1]

Ruft Repository- oder globale Optionen ab und setzt sie

git-fast-export[1]

Git-Datenexporteur

git-fast-import[1]

Backend für schnelle Git-Datenimporteure

git-filter-branch[1]

Schreibt Zweige neu

git-mergetool[1]

Führt Merge-Konfliktlösungs-Tools aus, um Merge-Konflikte zu lösen

git-pack-refs[1]

Packt Heads und Tags für einen effizienten Repository-Zugriff

git-prune[1]

Beschneidet alle unerreichbaren Objekte aus der Objektdatenbank

git-reflog[1]

Verwaltet Reflog-Informationen

git-refs[1]

Low-Level-Zugriff auf Refs

git-remote[1]

Verwaltet Sätze von verfolgten Repositories

git-repack[1]

Packt entpackte Objekte in einem Repository

git-replace[1]

Erstellt, listet, löscht Referenzen zum Ersetzen von Objekten

Interrogatoren

git-annotate[1]

Annotiert Zeilen einer Datei mit Commit-Informationen

git-blame[1]

Zeigt an, welche Revision und welcher Autor jede Zeile einer Datei zuletzt geändert hat

git-bugreport[1]

Sammelt Informationen für den Benutzer zur Einreichung eines Fehlerberichts

git-count-objects[1]

Zählt die Anzahl der entpackten Objekte und ihren Speicherplatzverbrauch

git-diagnose[1]

Erstellt ein ZIP-Archiv mit Diagnoseinformationen

git-difftool[1]

Zeigt Unterschiede mit gängigen Diff-Tools an

git-fsck[1]

Überprüft die Konnektivität und Gültigkeit der Objekte in der Datenbank

git-help[1]

Zeigt Hilfsinformationen zu Git an

git-instaweb[1]

Durchsuchen Sie Ihr Arbeitsrepository sofort in gitweb

git-merge-tree[1]

Führt einen Merge durch, ohne Index oder Arbeitsbaum zu berühren

git-rerere[1]

Wiederverwendet aufgezeichnete Lösungen für Konflikt-Merges

git-show-branch[1]

Zeigt Zweige und ihre Commits an

git-verify-commit[1]

Überprüft die GPG-Signatur von Commits

git-verify-tag[1]

Überprüft die GPG-Signatur von Tags

git-version[1]

Zeigt Versionsinformationen über Git an

git-whatchanged[1]

Zeigt Logs mit den Unterschieden, die jeder Commit einführt

gitweb[1]

Git Web-Schnittstelle (Web-Frontend für Git-Repositories)

Interaktion mit anderen

Diese Befehle dienen zur Interaktion mit fremden SCMs und mit anderen Personen über Patches per E-Mail.

git-archimport[1]

Importiert ein GNU Arch-Repository in Git

git-cvsexportcommit[1]

Exportiert einen einzelnen Commit in einen CVS-Checkout

git-cvsimport[1]

Rettet Ihre Daten aus einem anderen SCM, das andere gerne hassen

git-cvsserver[1]

Ein CVS-Server-Emulator für Git

git-imap-send[1]

Sendet eine Sammlung von Patches von stdin an einen IMAP-Ordner

git-p4[1]

Importiert aus und sendet an Perforce-Repositories

git-quiltimport[1]

Wendet einen Quilt-Patchset auf den aktuellen Zweig an

git-request-pull[1]

Erstellt eine Zusammenfassung der ausstehenden Änderungen

git-send-email[1]

Sendet eine Sammlung von Patches als E-Mails

git-svn[1]

Bidirektionale Operation zwischen einem Subversion-Repository und Git

Reset, Restore und Revert

Es gibt drei Befehle mit ähnlichen Namen: git reset, git restore und git revert.

  • git-revert[1] befasst sich damit, einen neuen Commit zu erstellen, der die von anderen Commits gemachten Änderungen rückgängig macht.

  • git-restore[1] befasst sich damit, Dateien im Arbeitsbaum entweder aus dem Index oder aus einem anderen Commit wiederherzustellen. Dieser Befehl aktualisiert Ihren Zweig nicht. Der Befehl kann auch verwendet werden, um Dateien im Index aus einem anderen Commit wiederherzustellen.

  • git-reset[1] befasst sich damit, Ihren Zweig zu aktualisieren und die Spitze zu verschieben, um Commits zum Zweig hinzuzufügen oder zu entfernen. Diese Operation ändert die Commit-Historie.

    git reset kann auch verwendet werden, um den Index wiederherzustellen, was sich mit git restore überschneidet.

Befehle auf niedriger Ebene (Plumbing)

Obwohl Git über eine eigene Porcelain-Schicht verfügt, reichen seine Low-Level-Befehle aus, um die Entwicklung alternativer Porcelains zu unterstützen. Entwickler solcher Porcelains beginnen vielleicht mit dem Lesen von git-update-index[1] und git-read-tree[1].

Die Schnittstelle (Eingabe, Ausgabe, Optionssatz und Semantik) zu diesen Low-Level-Befehlen ist darauf ausgelegt, weitaus stabiler zu sein als die Schnittstellen zu Porcelain-Befehlen, da diese Befehle hauptsächlich für die skriptgesteuerte Verwendung gedacht sind. Die Schnittstelle zu Porcelain-Befehlen kann hingegen geändert werden, um die Benutzerfreundlichkeit zu verbessern.

Die folgende Beschreibung unterteilt die Low-Level-Befehle in Befehle, die Objekte manipulieren (im Repository, Index und Arbeitsbaum), Befehle, die Objekte abfragen und vergleichen, und Befehle, die Objekte und Referenzen zwischen Repositories bewegen.

Manipulationsbefehle

git-apply[1]

Wendet einen Patch auf Dateien und/oder den Index an

git-checkout-index[1]

Kopiert Dateien aus dem Index in den Arbeitsbaum

git-commit-graph[1]

Schreibt und verifiziert Git Commit-Graph-Dateien

git-commit-tree[1]

Erstellt ein neues Commit-Objekt

git-hash-object[1]

Berechnet die Objekt-ID und erstellt optional ein Objekt aus einer Datei

git-index-pack[1]

Erstellt eine Pack-Indexdatei für ein vorhandenes gepacktes Archiv

git-merge-file[1]

Führt einen Drei-Wege-Dateimerge durch

git-merge-index[1]

Führt einen Merge für Dateien durch, die zusammengeführt werden müssen

git-mktag[1]

Erstellt ein Tag-Objekt mit zusätzlicher Validierung

git-mktree[1]

Erstellt ein Baum-Objekt aus ls-tree-formatiertem Text

git-multi-pack-index[1]

Schreibt und verifiziert Multi-Pack-Indizes

git-pack-objects[1]

Erstellt ein gepacktes Archiv von Objekten

git-prune-packed[1]

Entfernt zusätzliche Objekte, die bereits in Pack-Dateien vorhanden sind

git-read-tree[1]

Liest Baum-Informationen in den Index

git-replay[1]

EXPERIMENTELL: Wendet Commits auf einer neuen Basis erneut an, funktioniert auch mit Bare-Repositories

git-symbolic-ref[1]

Liest, modifiziert und löscht symbolische Referenzen

git-unpack-objects[1]

Objekte aus einem gepackten Archiv entpacken

git-update-index[1]

Dateiinhalte im Arbeitsbaum im Index registrieren

git-update-ref[1]

Sicher den Objekt-Namen in einem Ref aktualisieren

git-write-tree[1]

Einen Baum-Objekt aus dem aktuellen Index erstellen

Abfragebefehle

git-cat-file[1]

Inhalte oder Details von Repository-Objekten bereitstellen

git-cherry[1]

Commits finden, die noch nicht auf den Upstream angewendet wurden

git-diff-files[1]

Dateien im Arbeitsbaum und im Index vergleichen

git-diff-index[1]

Einen Baum mit dem Arbeitsbaum oder dem Index vergleichen

git-diff-pairs[1]

Inhalt und Modus von bereitgestellten Blob-Paaren vergleichen

git-diff-tree[1]

Inhalt und Modus von Blobs vergleichen, die über zwei Baum-Objekte gefunden wurden

git-for-each-ref[1]

Informationen über jeden Ref ausgeben

git-for-each-repo[1]

Einen Git-Befehl auf einer Liste von Repositories ausführen

git-get-tar-commit-id[1]

Commit-ID aus einem mit git-archive erstellten Archiv extrahieren

git-last-modified[1]

EXPERIMENTELL: Zeigen, wann Dateien zuletzt geändert wurden

git-ls-files[1]

Informationen über Dateien im Index und im Arbeitsbaum anzeigen

git-ls-remote[1]

Referenzen in einem entfernten Repository auflisten

git-ls-tree[1]

Den Inhalt eines Baum-Objekts auflisten

git-merge-base[1]

Möglichst gute gemeinsame Vorfahren für einen Merge finden

git-name-rev[1]

Symbolische Namen für gegebene Revisionen finden

git-pack-redundant[1]

Redundante Pack-Dateien finden

git-repo[1]

Informationen über das Repository abrufen

git-rev-list[1]

Commit-Objekte in umgekehrt chronologischer Reihenfolge auflisten

git-rev-parse[1]

Parameter auswählen und bearbeiten

git-show-index[1]

Index eines gepackten Archivs anzeigen

git-show-ref[1]

Referenzen in einem lokalen Repository auflisten

git-unpack-file[1]

Erzeugt eine temporäre Datei mit dem Inhalt eines Blobs

git-var[1]

Einen logischen Git-Variablenwert anzeigen

git-verify-pack[1]

Gepackte Git-Archivdateien validieren

Generell berühren die Abfragebefehle die Dateien im Arbeitsbaum nicht.

Synchronisieren von Repositories

git-daemon[1]

Ein sehr einfacher Server für Git-Repositories

git-fetch-pack[1]

Fehlende Objekte von einem anderen Repository empfangen

git-http-backend[1]

Serverseitige Implementierung von Git über HTTP

git-send-pack[1]

Objekte über das Git-Protokoll an ein anderes Repository senden

git-update-server-info[1]

Hilfsdatei aktualisieren, um "dumme" Server zu unterstützen

Die folgenden sind Hilfsbefehle, die von den obigen Befehlen verwendet werden; Endbenutzer verwenden sie normalerweise nicht direkt.

git-http-fetch[1]

Von einem entfernten Git-Repository über HTTP herunterladen

git-http-push[1]

Objekte über HTTP/DAV an ein anderes Repository senden

git-receive-pack[1]

Empfangen, was in das Repository gepusht wurde

git-shell[1]

Eingeschränkte Login-Shell für reinen Git-SSH-Zugang

git-upload-archive[1]

Archiv an git-archive zurücksenden

git-upload-pack[1]

Objekte gepackt an git-fetch-pack zurücksenden

Interne Hilfsbefehle

Dies sind interne Hilfsbefehle, die von anderen Befehlen verwendet werden; Endbenutzer verwenden sie normalerweise nicht direkt.

git-check-attr[1]

gitattributes-Informationen anzeigen

git-check-ignore[1]

gitignore / exclude-Dateien debuggen

git-check-mailmap[1]

Kanonische Namen und E-Mail-Adressen von Kontakten anzeigen

git-check-ref-format[1]

Stellt sicher, dass ein Referenzname korrekt formatiert ist

git-column[1]

Daten in Spalten anzeigen

git-credential[1]

Benutzeranmeldeinformationen abrufen und speichern

git-credential-cache[1]

Helfer zum temporären Speichern von Passwörtern im Speicher

git-credential-store[1]

Helfer zum Speichern von Anmeldeinformationen auf der Festplatte

git-fmt-merge-msg[1]

Eine Merge-Commit-Nachricht erstellen

git-hook[1]

Git-Hooks ausführen

git-interpret-trailers[1]

Strukturierte Informationen in Commit-Nachrichten hinzufügen oder parsen

git-mailinfo[1]

Patch und Autorschaft aus einer einzelnen E-Mail-Nachricht extrahieren

git-mailsplit[1]

Einfaches UNIX mbox-Splitterprogramm

git-merge-one-file[1]

Das Standard-Hilfsprogramm für git-merge-index

git-patch-id[1]

Eindeutige ID für einen Patch berechnen

git-sh-i18n[1]

Git's i18n-Setup-Code für Shell-Skripte

git-sh-setup[1]

Gemeinsamer Setup-Code für Git-Shell-Skripte

git-stripspace[1]

Unnötige Leerzeichen entfernen

Anleitungen

Die folgenden Dokumentationsseiten sind Anleitungen zu Git-Konzepten.

gitcore-tutorial[7]

Ein Git-Core-Tutorial für Entwickler

gitcredentials[7]

Bereitstellung von Benutzernamen und Passwörtern für Git

gitcvs-migration[7]

Git für CVS-Benutzer

gitdiffcore[7]

Anpassen der Diff-Ausgabe

giteveryday[7]

Ein nützlicher Mindestsatz von Befehlen für den täglichen Git-Gebrauch

gitfaq[7]

Häufig gestellte Fragen zur Verwendung von Git

gitglossary[7]

Ein Git-Glossar

gitnamespaces[7]

Git-Namensräume

gitremote-helpers[7]

Hilfsprogramme zur Interaktion mit entfernten Repositories

gitsubmodules[7]

Ein Repository innerhalb eines anderen einbinden

gittutorial[7]

Eine Einführung in Git

gittutorial-2[7]

Eine Einführung in Git: Teil zwei

gitworkflows[7]

Eine Übersicht über empfohlene Arbeitsabläufe mit Git

Repository-, Befehls- und Dateischnittstellen

Diese Dokumentation bespricht Repository- und Befehlsschnittstellen, mit denen Benutzer direkt interagieren sollen. Weitere Details zu den Kriterien finden Sie unter --user-formats in git-help[1].

gitattributes[5]

Attribute pro Pfad definieren

gitcli[7]

Git-Befehlszeilenschnittstelle und Konventionen

githooks[5]

Von Git verwendete Hooks

gitignore[5]

Definiert absichtlich nicht verfolgte Dateien, die ignoriert werden sollen

gitmailmap[5]

Autoren-/Committernamen und/oder E-Mail-Adressen zuordnen

gitmodules[5]

Submodul-Eigenschaften definieren

gitrepository-layout[5]

Git-Repository-Layout

gitrevisions[7]

Revisionen und Bereiche für Git spezifizieren

Dateiformate, Protokolle und andere Entwicklerschnittstellen

Diese Dokumentation bespricht Dateiformate, übertragene Protokolle und andere Git-Entwicklerschnittstellen. Siehe --developer-interfaces in git-help[1].

gitformat-bundle[5]

Das Bundle-Dateiformat

gitformat-chunk[5]

Chunk-basierte Dateiformate

gitformat-commit-graph[5]

Git Commit-Graph-Format

gitformat-index[5]

Git-Index-Format

gitformat-pack[5]

Git-Pack-Format

gitformat-signature[5]

Git kryptografische Signaturformate

gitprotocol-capabilities[5]

Protokoll v0 und v1 Fähigkeiten

gitprotocol-common[5]

Gemeinsamkeiten verschiedener Protokolle

gitprotocol-http[5]

Git HTTP-basierte Protokolle

gitprotocol-pack[5]

Wie Packs über das Netzwerk übertragen werden

gitprotocol-v2[5]

Git Wire Protocol, Version 2

Konfigurationsmechanismus

Git verwendet ein einfaches Textformat, um Anpassungen zu speichern, die pro Repository und pro Benutzer gelten. Eine solche Konfigurationsdatei kann wie folgt aussehen

#
# A '#' or ';' character indicates a comment.
#

; core variables
[core]
	; Don't trust file modes
	filemode = false

; user identity
[user]
	name = "Junio C Hamano"
	email = "gitster@pobox.com"

Verschiedene Befehle lesen aus der Konfigurationsdatei und passen ihre Operationen entsprechend an. Siehe git-config[1] für eine Liste und weitere Details zum Konfigurationsmechanismus.

Terminologie für Bezeichner

<object>

Gibt den Objekt-Namen für jeden Objekttyp an.

<blob>

Gibt einen Blob-Objekt-Namen an.

<tree>

Gibt einen Baum-Objekt-Namen an.

<commit>

Gibt einen Commit-Objekt-Namen an.

<tree-ish>

Gibt einen Baum-, Commit- oder Tag-Objektnamen an. Ein Befehl, der ein <tree-ish>-Argument nimmt, möchte letztendlich mit einem Baum-Objekt arbeiten, dereferenziert aber automatisch Commit- und Tag-Objekte, die auf ein Baum-Objekt verweisen.

<commit-ish>

Gibt einen Commit- oder Tag-Objektnamen an. Ein Befehl, der ein <commit-ish>-Argument nimmt, möchte letztendlich mit einem Commit-Objekt arbeiten, dereferenziert aber automatisch Tag-Objekte, die auf einen Commit verweisen.

<type>

Gibt an, dass ein Objekttyp erforderlich ist. Derzeit einer von: blob, tree, commit oder tag.

<file>

Gibt einen Dateinamen an – fast immer relativ zum Wurzelverzeichnis der Baumstruktur, die GIT_INDEX_FILE beschreibt.

Symbolische Bezeichner

Jeder Git-Befehl, der ein <object> akzeptiert, kann auch die folgende symbolische Notation verwenden

HEAD

bezeichnet den Kopf des aktuellen Branches.

<tag>

ein gültiger Tag-Name (d.h. eine refs/tags/<tag> Referenz).

<head>

ein gültiger Head-Name (d.h. eine refs/heads/<head> Referenz).

Eine vollständigere Liste von Möglichkeiten, Objekt-Namen zu schreiben, finden Sie im Abschnitt "SPECIFYING REVISIONS" in gitrevisions[7].

Datei-/Verzeichnisstruktur

Bitte sehen Sie das Dokument gitrepository-layout[5].

Lesen Sie githooks[5] für weitere Details zu jedem Hook.

Höher entwickelte SCMs können zusätzliche Informationen im $GIT_DIR bereitstellen und verwalten.

Terminologie

Bitte sehen Sie gitglossary[7].

Umgebungsvariablen

Verschiedene Git-Befehle beachten Umgebungsvariablen und ändern ihr Verhalten. Die als "Boolean" gekennzeichneten Umgebungsvariablen nehmen ihre Werte auf die gleiche Weise an wie boolesche Konfigurationsvariablen, d.h. "true", "yes", "on" und positive Zahlen werden als "yes" interpretiert, während "false", "no", "off" und "0" als "no" interpretiert werden.

Hier sind die Variablen

System

HOME

Gibt den Pfad zum Home-Verzeichnis des Benutzers an. Unter Windows, wenn nicht gesetzt, setzt Git eine Prozessumgebungsvariable gleich: $HOMEDRIVE$HOMEPATH, wenn sowohl $HOMEDRIVE als auch $HOMEPATH existieren; andernfalls $USERPROFILE, wenn $USERPROFILE existiert.

Das Git-Repository

Diese Umgebungsvariablen gelten für *alle* Kern-Git-Befehle. Hinweis: Es ist erwähnenswert, dass sie von SCMs oberhalb von Git verwendet/überschrieben werden können, also seien Sie vorsichtig, wenn Sie ein fremdes Frontend verwenden.

GIT_INDEX_FILE

Diese Umgebungsvariable gibt eine alternative Indexdatei an. Wenn sie nicht angegeben ist, wird der Standard $GIT_DIR/index verwendet.

GIT_INDEX_VERSION

Diese Umgebungsvariable gibt an, welche Indexversion beim Schreiben der Indexdatei verwendet wird. Sie hat keine Auswirkungen auf bestehende Indexdateien. Standardmäßig wird Indexdatei-Version 2 oder 3 verwendet. Siehe git-update-index[1] für weitere Informationen.

GIT_OBJECT_DIRECTORY

Wenn das Objekt-Speicherverzeichnis über diese Umgebungsvariable angegeben wird, werden die sha1-Verzeichnisse darunter erstellt – andernfalls wird das Standardverzeichnis $GIT_DIR/objects verwendet.

GIT_ALTERNATE_OBJECT_DIRECTORIES

Aufgrund der unveränderlichen Natur von Git-Objekten können alte Objekte in gemeinsame, schreibgeschützte Verzeichnisse archiviert werden. Diese Variable gibt eine durch ":" getrennte (unter Windows durch ";" getrennte) Liste von Git-Objektverzeichnissen an, die zur Suche nach Git-Objekten verwendet werden können. Neue Objekte werden nicht in diese Verzeichnisse geschrieben.

Einträge, die mit " (doppeltes Anführungszeichen) beginnen, werden als C-artige Anführungszeichenpfade interpretiert, wobei führende und nachfolgende doppelte Anführungszeichen entfernt und Backslash-Escapes beachtet werden. Z.B. der Wert "path-with-\"-and-:-in-it":vanilla-path hat zwei Pfade: path-with-"-and-:-in-it und vanilla-path.

GIT_DIR

Wenn die Umgebungsvariable GIT_DIR gesetzt ist, gibt sie einen Pfad an, der anstelle des Standards .git für die Basis des Repositorys verwendet wird. Die Kommandozeilenoption --git-dir setzt diesen Wert ebenfalls.

GIT_WORK_TREE

Setzt den Pfad zum Stammverzeichnis des Arbeitsbaums. Dies kann auch durch die Kommandozeilenoption --work-tree und die Konfigurationsvariable core.worktree gesteuert werden.

GIT_NAMESPACE

Setzt den Git-Namensraum; siehe gitnamespaces[7] für Details. Die Kommandozeilenoption --namespace setzt diesen Wert ebenfalls.

GIT_CEILING_DIRECTORIES

Dies sollte eine durch Doppelpunkte getrennte Liste von absoluten Pfaden sein. Wenn gesetzt, ist dies eine Liste von Verzeichnissen, in die Git nicht wechseln soll, während es nach einem Repository-Verzeichnis sucht (nützlich zum Ausschließen langsam ladender Netzwerkverzeichnisse). Es schließt das aktuelle Arbeitsverzeichnis oder ein über die Befehlszeile oder Umgebung gesetztes GIT_DIR nicht aus. Normalerweise muss Git die Einträge in dieser Liste lesen und alle eventuell vorhandenen Symlinks auflösen, um sie mit dem aktuellen Verzeichnis zu vergleichen. Wenn jedoch selbst dieser Zugriff langsam ist, können Sie einen leeren Eintrag zur Liste hinzufügen, um Git mitzuteilen, dass die nachfolgenden Einträge keine Symlinks sind und nicht aufgelöst werden müssen; z.B. GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.

GIT_DISCOVERY_ACROSS_FILESYSTEM

Wenn Git in einem Verzeichnis ausgeführt wird, das kein ".git" Repository-Verzeichnis hat, versucht es, ein solches Verzeichnis in den übergeordneten Verzeichnissen zu finden, um die Spitze des Arbeitsbaums zu finden, aber standardmäßig überschreitet es keine Dateisystemgrenzen. Diese boolesche Umgebungsvariable kann auf true gesetzt werden, um Git anzuweisen, nicht an Dateisystemgrenzen zu stoppen. Wie GIT_CEILING_DIRECTORIES wird dies kein explizites Repository-Verzeichnis beeinflussen, das über GIT_DIR oder auf der Befehlszeile gesetzt wurde.

GIT_COMMON_DIR

Wenn diese Variable auf einen Pfad gesetzt ist, werden Nicht-Arbeitsbaum-Dateien, die normalerweise in $GIT_DIR liegen, stattdessen aus diesem Pfad genommen. Arbeitsbaum-spezifische Dateien wie HEAD oder Index werden aus $GIT_DIR genommen. Siehe gitrepository-layout[5] und git-worktree[1] für Details. Diese Variable hat eine geringere Priorität als andere Pfadvariablen wie GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...

GIT_DEFAULT_HASH

Wenn diese Variable gesetzt ist, wird der Standard-Hash-Algorithmus für neue Repositories auf diesen Wert gesetzt. Dieser Wert wird beim Klonen ignoriert und die Einstellung des entfernten Repositorys wird immer verwendet. Der Standard ist "sha1". Siehe --object-format in git-init[1].

GIT_DEFAULT_REF_FORMAT

Wenn diese Variable gesetzt ist, wird das Standard-Referenz-Backend-Format für neue Repositories auf diesen Wert gesetzt. Der Standard ist "files". Siehe --ref-format in git-init[1].

Git-Commits

GIT_AUTHOR_NAME

Der lesbare Name, der in der Autorenidentität bei der Erstellung von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Konfigurationseinstellungen user.name und author.name.

GIT_AUTHOR_EMAIL

Die E-Mail-Adresse, die in der Autorenidentität bei der Erstellung von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Konfigurationseinstellungen user.email und author.email.

GIT_AUTHOR_DATE

Das Datum, das für die Autorenidentität bei der Erstellung von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Gültige Formate finden Sie in git-commit[1].

GIT_COMMITTER_NAME

Der lesbare Name, der in der Committer-Identität bei der Erstellung von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Konfigurationseinstellungen user.name und committer.name.

GIT_COMMITTER_EMAIL

Die E-Mail-Adresse, die in der Autorenidentität bei der Erstellung von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Konfigurationseinstellungen user.email und committer.email.

GIT_COMMITTER_DATE

Das Datum, das für die Committer-Identität bei der Erstellung von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Gültige Formate finden Sie in git-commit[1].

EMAIL

Die E-Mail-Adresse, die in der Autoren- und Committer-Identität verwendet wird, wenn keine andere relevante Umgebungsvariable oder Konfigurationseinstellung gesetzt wurde.

Git Diffs

GIT_DIFF_OPTS

Nur gültige Einstellung ist "--unified=??" oder "-u??" um die Anzahl der Kontextzeilen festzulegen, die bei der Erstellung eines Unified Diffs angezeigt werden. Dies hat Vorrang vor jedem "-U" oder "--unified" Optionswert, der auf der Git diff Befehlszeile übergeben wird.

GIT_EXTERNAL_DIFF

Wenn die Umgebungsvariable GIT_EXTERNAL_DIFF gesetzt ist, wird das durch sie benannte Programm zum Erzeugen von Diffs aufgerufen, und Git verwendet nicht seine interne Diff-Maschinerie. Für einen hinzugefügten, entfernten oder geänderten Pfad wird GIT_EXTERNAL_DIFF mit 7 Parametern aufgerufen

path old-file old-hex old-mode new-file new-hex new-mode

wobei

<old|new>-file

Dateien sind, die GIT_EXTERNAL_DIFF zum Lesen des Inhalts von <old|new> verwenden kann,

<old|new>-hex

die 40-stelligen SHA-1-Hashes sind,

<old|new>-mode

die oktale Darstellung der Dateimodi sind.

Die Datei-Parameter können auf die Arbeitsdatei des Benutzers zeigen (z.B. new-file in "git-diff-files"), /dev/null (z.B. old-file, wenn eine neue Datei hinzugefügt wird) oder eine temporäre Datei (z.B. old-file im Index). GIT_EXTERNAL_DIFF muss sich nicht um das Unlinking der temporären Datei kümmern – sie wird entfernt, wenn GIT_EXTERNAL_DIFF beendet wird.

Für einen nicht zusammengeführten Pfad wird GIT_EXTERNAL_DIFF mit 1 Parameter, <path>, aufgerufen.

Für jeden Pfad, für den GIT_EXTERNAL_DIFF aufgerufen wird, werden zwei Umgebungsvariablen gesetzt: GIT_DIFF_PATH_COUNTER und GIT_DIFF_PATH_TOTAL.

GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE

Wenn diese boolesche Umgebungsvariable auf true gesetzt ist, wird erwartet, dass der Befehl GIT_EXTERNAL_DIFF den Exit-Code 0 zurückgibt, wenn er die Eingabedateien als gleich betrachtet, oder 1, wenn er sie als unterschiedlich betrachtet, ähnlich wie diff(1). Wenn sie auf false gesetzt ist, was der Standard ist, wird erwartet, dass der Befehl unabhängig von der Gleichheit den Exit-Code 0 zurückgibt. Jeder andere Exit-Code führt dazu, dass Git einen fatalen Fehler meldet.

GIT_DIFF_PATH_COUNTER

Ein 1-basierter Zähler, der für jeden Pfad um eins erhöht wird.

GIT_DIFF_PATH_TOTAL

Die Gesamtzahl der Pfade.

andere

GIT_MERGE_VERBOSITY

Eine Zahl, die die Menge der von der rekursiven Merge-Strategie angezeigten Ausgaben steuert. Überschreibt merge.verbosity. Siehe git-merge[1]

GIT_PAGER

Diese Umgebungsvariable überschreibt $PAGER. Wenn sie auf eine leere Zeichenkette oder den Wert "cat" gesetzt ist, startet Git keinen Pager. Siehe auch die Option core.pager in git-config[1].

GIT_PROGRESS_DELAY

Eine Zahl, die steuert, wie viele Sekunden gewartet wird, bevor optionale Fortschrittsanzeigen angezeigt werden. Standardwert ist 1.

GIT_EDITOR

Diese Umgebungsvariable überschreibt $EDITOR und $VISUAL. Sie wird von mehreren Git-Befehlen verwendet, wenn im interaktiven Modus ein Editor gestartet werden soll. Siehe auch git-var[1] und die Option core.editor in git-config[1].

GIT_SEQUENCE_EDITOR

Diese Umgebungsvariable überschreibt den konfigurierten Git-Editor beim Bearbeiten der To-do-Liste eines interaktiven Rebase. Siehe auch git-rebase[1] und die Option sequence.editor in git-config[1].

GIT_SSH
GIT_SSH_COMMAND

Wenn eine dieser Umgebungsvariablen gesetzt ist, verwenden git fetch und git push den angegebenen Befehl anstelle von ssh, wenn sie sich mit einem entfernten System verbinden müssen. Die an den konfigurierten Befehl übergebenen Kommandozeilenparameter werden durch die SSH-Variante bestimmt. Siehe die Option ssh.variant in git-config[1] für Details.

$GIT_SSH_COMMAND hat Vorrang vor $GIT_SSH und wird von der Shell interpretiert, was die Einbeziehung zusätzlicher Argumente ermöglicht. $GIT_SSH hingegen muss nur der Pfad zu einem Programm sein (der ein Wrapper-Shell-Skript sein kann, wenn zusätzliche Argumente benötigt werden).

Normalerweise ist es einfacher, gewünschte Optionen über Ihre persönliche .ssh/config-Datei zu konfigurieren. Bitte konsultieren Sie Ihre SSH-Dokumentation für weitere Details.

GIT_SSH_VARIANT

Wenn diese Umgebungsvariable gesetzt ist, überschreibt sie die automatische Erkennung von Git, ob GIT_SSH/GIT_SSH_COMMAND/core.sshCommand auf OpenSSH, plink oder tortoiseplink verweisen. Diese Variable überschreibt die Konfigurationseinstellung ssh.variant, die denselben Zweck erfüllt.

GIT_SSL_NO_VERIFY

Das Setzen und Exportieren dieser Umgebungsvariable auf einen beliebigen Wert weist Git an, das SSL-Zertifikat beim Abrufen oder Pushen über HTTPS nicht zu überprüfen.

GIT_ATTR_SOURCE

Setzt den Treeish, von dem gitattributes gelesen werden sollen.

GIT_ASKPASS

Wenn diese Umgebungsvariable gesetzt ist, rufen Git-Befehle, die Passwörter oder Passphrasen benötigen (z. B. für HTTP- oder IMAP-Authentifizierung), dieses Programm mit einer geeigneten Aufforderung als Kommandozeilenargument auf und lesen das Passwort von dessen STDOUT. Siehe auch die Option core.askPass in git-config[1].

GIT_TERMINAL_PROMPT

Wenn diese boolesche Umgebungsvariable auf false gesetzt ist, fragt Git nicht auf dem Terminal nach (z. B. bei der Aufforderung zur HTTP-Authentifizierung).

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM

Nimmt die Konfiguration aus den angegebenen Dateien anstelle von globalen oder systemweiten Konfigurationsdateien. Wenn GIT_CONFIG_SYSTEM gesetzt ist, wird die zur Erstellungszeit definierte Systemkonfigurationsdatei (normalerweise /etc/gitconfig) nicht gelesen. Ebenso werden, wenn GIT_CONFIG_GLOBAL gesetzt ist, weder $HOME/.gitconfig noch $XDG_CONFIG_HOME/git/config gelesen. Kann auf /dev/null gesetzt werden, um das Lesen von Konfigurationsdateien der jeweiligen Ebene zu überspringen.

GIT_CONFIG_NOSYSTEM

Ob Einstellungen aus der systemweiten Datei $(prefix)/etc/gitconfig übersprungen werden sollen. Diese boolesche Umgebungsvariable kann zusammen mit $HOME und $XDG_CONFIG_HOME verwendet werden, um eine vorhersagbare Umgebung für ein wählerisches Skript zu schaffen, oder Sie können sie auf true setzen, um eine fehlerhafte /etc/gitconfig-Datei vorübergehend zu vermeiden, während Sie auf jemanden mit ausreichenden Berechtigungen warten, um sie zu beheben.

GIT_FLUSH

Wenn diese boolesche Umgebungsvariable auf true gesetzt ist, erzwingen Befehle wie git blame (im inkrementellen Modus), git rev-list, git log, git check-attr und git check-ignore einen Flush des Ausgabestroms, nachdem jeder Datensatz geleert wurde. Wenn diese Variable auf false gesetzt ist, erfolgt die Ausgabe dieser Befehle über vollständig gepufferte I/O. Wenn diese Umgebungsvariable nicht gesetzt ist, wählt Git die gepufferte oder datensatzorientierte Ausgabe basierend darauf, ob stdout an eine Datei umgeleitet zu sein scheint oder nicht.

GIT_TRACE

Aktiviert allgemeine Trace-Nachrichten, z. B. Alias-Expansion, Ausführung von internen Befehlen und externen Befehlen.

Wenn diese Variable auf "1", "2" oder "true" gesetzt ist (Vergleich ist nicht case-sensitiv), werden Trace-Nachrichten nach stderr gedruckt.

Wenn die Variable auf einen ganzzahligen Wert größer als 2 und kleiner als 10 (strikt) gesetzt ist, interpretiert Git diesen Wert als offenes Dateideskriptor und versucht, die Trace-Nachrichten in diesen Dateideskriptor zu schreiben.

Alternativ, wenn die Variable auf einen absoluten Pfad gesetzt ist (beginnend mit einem /-Zeichen), interpretiert Git dies als Dateipfad und versucht, die Trace-Nachrichten anzuhängen.

Das Entfernen der Variablen oder das Setzen auf leer, "0" oder "false" (nicht case-sensitiv) deaktiviert Trace-Nachrichten.

GIT_TRACE_FSMONITOR

Aktiviert Trace-Nachrichten für die Dateisystem-Monitor-Erweiterung. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_PACK_ACCESS

Aktiviert Trace-Nachrichten für alle Zugriffe auf Packs. Für jeden Zugriff werden der Pack-Dateiname und ein Offset im Pack aufgezeichnet. Dies kann bei der Fehlerbehebung bei einigen Pack-bezogenen Leistungsproblemen hilfreich sein. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_PACKET

Aktiviert Trace-Nachrichten für alle Pakete, die in ein bestimmtes Programm hinein- oder herausgehen. Dies kann bei der Fehlersuche von Objektverhandlungen oder anderen Protokollproblemen helfen. Das Tracing wird bei einem Paket abgeschaltet, das mit "PACK" beginnt (aber siehe GIT_TRACE_PACKFILE unten). Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_PACKFILE

Aktiviert das Tracing von Packfiles, die von einem bestimmten Programm gesendet oder empfangen werden. Im Gegensatz zu anderen Trace-Ausgaben ist dieser Trace unverändert: keine Header und keine Anführungszeichen für Binärdaten. Sie möchten ihn fast sicher in eine Datei umleiten (z. B. GIT_TRACE_PACKFILE=/tmp/my.pack), anstatt ihn auf dem Terminal anzuzeigen oder ihn mit anderen Trace-Ausgaben zu vermischen.

Beachten Sie, dass dies derzeit nur für die Client-Seite von Klonen und Abrufen implementiert ist.

GIT_TRACE_PERFORMANCE

Aktiviert leistungsbezogene Trace-Nachrichten, z. B. die Gesamtausführungszeit jedes Git-Befehls. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_REFS

Aktiviert Trace-Nachrichten für Operationen auf der Ref-Datenbank. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_SETUP

Aktiviert Trace-Nachrichten, die .git, den Arbeitsbaum und das aktuelle Arbeitsverzeichnis ausgeben, nachdem Git seine Setup-Phase abgeschlossen hat. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_SHALLOW

Aktiviert Trace-Nachrichten, die beim Abrufen/Klonen von flachen Repositories zur Fehlerbehebung beitragen können. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_CURL

Aktiviert einen vollständigen Curl-Trace-Dump aller eingehenden und ausgehenden Daten, einschließlich beschreibender Informationen, des Git-Transportprotokolls. Dies ähnelt der Ausführung von curl --trace-ascii auf der Kommandozeile. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_CURL_NO_DATA

Wenn ein Curl-Trace aktiviert ist (siehe GIT_TRACE_CURL oben), werden keine Daten ausgegeben (d. h. nur Infozeilen und Header werden ausgegeben).

GIT_TRACE2

Aktiviert detailliertere Trace-Nachrichten aus der "trace2"-Bibliothek. Die Ausgabe von GIT_TRACE2 ist ein einfaches textbasiertes Format für die menschliche Lesbarkeit.

Wenn diese Variable auf "1", "2" oder "true" gesetzt ist (Vergleich ist nicht case-sensitiv), werden Trace-Nachrichten nach stderr gedruckt.

Wenn die Variable auf einen ganzzahligen Wert größer als 2 und kleiner als 10 (strikt) gesetzt ist, interpretiert Git diesen Wert als offenes Dateideskriptor und versucht, die Trace-Nachrichten in diesen Dateideskriptor zu schreiben.

Alternativ, wenn die Variable auf einen absoluten Pfad gesetzt ist (beginnend mit einem /-Zeichen), interpretiert Git dies als Dateipfad und versucht, die Trace-Nachrichten anzuhängen. Wenn der Pfad bereits existiert und ein Verzeichnis ist, werden die Trace-Nachrichten in Dateien (eine pro Prozess) in diesem Verzeichnis geschrieben, benannt nach der letzten Komponente der SID und einem optionalen Zähler (um Namenskollisionen zu vermeiden).

Zusätzlich, wenn die Variable auf af_unix:[<socket-type>:]<absolute-pathname> gesetzt ist, versucht Git, den Pfad als Unix Domain Socket zu öffnen. Der Socket-Typ kann entweder stream oder dgram sein.

Das Entfernen der Variablen oder das Setzen auf leer, "0" oder "false" (nicht case-sensitiv) deaktiviert Trace-Nachrichten.

Siehe Trace2 Dokumentation für vollständige Details.

GIT_TRACE2_EVENT

Diese Einstellung schreibt ein JSON-basiertes Format, das für maschinelle Interpretation geeignet ist. Siehe GIT_TRACE2 für verfügbare Trace-Ausgabeoptionen und Trace2 Dokumentation für vollständige Details.

GIT_TRACE2_PERF

Zusätzlich zu den textbasierten Nachrichten, die in GIT_TRACE2 verfügbar sind, schreibt diese Einstellung ein spaltenbasiertes Format zum Verständnis von verschachtelten Regionen. Siehe GIT_TRACE2 für verfügbare Trace-Ausgabeoptionen und Trace2 Dokumentation für vollständige Details.

GIT_TRACE_REDACT

Standardmäßig, wenn das Tracing aktiviert ist, schwärzt Git die Werte von Cookies, dem "Authorization:"-Header, dem "Proxy-Authorization:"-Header und Packfile-URIs. Setzen Sie diese boolesche Umgebungsvariable auf false, um diese Schwärzung zu verhindern.

GIT_NO_REPLACE_OBJECTS

Das Setzen und Exportieren dieser Umgebungsvariable weist Git an, Ersetzungs-Refs zu ignorieren und keine Git-Objekte zu ersetzen.

GIT_LITERAL_PATHSPECS

Das Setzen dieser booleschen Umgebungsvariable auf true bewirkt, dass Git alle Pfadangaben buchstäblich behandelt und nicht als Glob-Muster. Zum Beispiel sucht die Ausführung von GIT_LITERAL_PATHSPECS=1 git log -- *.c' nach Commits, die den Pfad *.c berühren, und nicht nach Pfaden, die der Glob *.c abgleicht. Sie möchten dies vielleicht, wenn Sie buchstäbliche Pfade an Git übergeben (z. B. Pfade, die Ihnen zuvor von git ls-tree, --raw Diff-Ausgabe usw. gegeben wurden).

GIT_GLOB_PATHSPECS

Das Setzen dieser booleschen Umgebungsvariable auf true bewirkt, dass Git alle Pfadangaben als Glob-Muster behandelt (auch bekannt als "glob" Magic).

GIT_NOGLOB_PATHSPECS

Das Setzen dieser booleschen Umgebungsvariable auf true bewirkt, dass Git alle Pfadangaben als buchstäblich behandelt (auch bekannt als "literal" Magic).

GIT_ICASE_PATHSPECS

Das Setzen dieser booleschen Umgebungsvariable auf true bewirkt, dass Git alle Pfadangaben als case-insensitiv behandelt.

GIT_NO_LAZY_FETCH

Das Setzen dieser booleschen Umgebungsvariable auf true weist Git an, fehlende Objekte vom Promisor-Remote bei Bedarf nicht verzögert abzurufen.

GIT_REFLOG_ACTION

Wenn ein Ref aktualisiert wird, werden Reflog-Einträge erstellt, um den Grund für die Aktualisierung des Refs (typischerweise der Name des High-Level-Befehls, der das Ref aktualisiert hat) zusätzlich zu den alten und neuen Werten des Refs zu verfolgen. Ein skriptbasierter Porcelain-Befehl kann die Hilfsfunktion set_reflog_action in git-sh-setup verwenden, um seinen Namen dieser Variablen zuzuweisen, wenn er als Top-Level-Befehl vom Endbenutzer aufgerufen wird, um im Body des Reflogs aufgezeichnet zu werden.

GIT_REF_PARANOIA

Wenn diese boolesche Umgebungsvariable auf false gesetzt ist, werden fehlerhafte oder schlecht benannte Refs beim Iterieren über Ref-Listen ignoriert. Normalerweise versucht Git, solche Refs einzubeziehen, was dazu führen kann, dass einige Operationen fehlschlagen. Dies ist normalerweise vorzuziehen, da potenziell destruktive Operationen (z. B. git-prune[1]) besser abbrechen, als fehlerhafte Refs zu ignorieren (und somit die von ihnen referenzierten Verläufe als nicht speicherungswert zu betrachten). Der Standardwert ist 1 (d. h. paranoid bei der Erkennung und beim Abbruch aller Operationen). Sie müssen dies normalerweise nicht auf 0 setzen, aber es kann nützlich sein, wenn Sie versuchen, Daten aus einem beschädigten Repository zu retten.

GIT_COMMIT_GRAPH_PARANOIA

Beim Laden eines Commit-Objekts aus dem Commit-Graphen führt Git eine Existenzprüfung des Objekts in der Objektdatenbank durch. Dies geschieht, um Probleme mit veralteten Commit-Graphen zu vermeiden, die Verweise auf bereits gelöschte Commits enthalten, geht aber mit einem Leistungsabzug einher.

Der Standardwert ist "false", was das oben genannte Verhalten deaktiviert. Das Setzen auf "true" aktiviert die Existenzprüfung, sodass veraltete Commits nie aus dem Commit-Graphen zurückgegeben werden, auf Kosten der Leistung.

GIT_ALLOW_PROTOCOL

Wenn auf eine durch Doppelpunkte getrennte Liste von Protokollen gesetzt, verhält es sich so, als ob protocol.allow auf never gesetzt wäre, und jedes der aufgeführten Protokolle hätte protocol.<name>.allow auf always gesetzt (wobei jede bestehende Konfiguration überschrieben wird). Siehe die Beschreibung von protocol.allow in git-config[1] für weitere Details.

GIT_PROTOCOL_FROM_USER

Setzen Sie diese boolesche Umgebungsvariable auf false, um Protokolle zu verhindern, die von fetch/push/clone verwendet werden und auf den user-Zustand konfiguriert sind. Dies ist nützlich, um die rekursive Initialisierung von Submodulen aus einem nicht vertrauenswürdigen Repository zu beschränken oder für Programme, die potenziell nicht vertrauenswürdige URLs an Git-Befehle übergeben. Siehe git-config[1] für weitere Details.

GIT_PROTOCOL

Nur für den internen Gebrauch. Wird beim Handshake des Wire-Protokolls verwendet. Enthält eine durch Doppelpunkte getrennte Liste von Schlüsseln mit optionalen Werten <key>[=<value>]. Das Vorhandensein unbekannter Schlüssel und Werte muss ignoriert werden.

Beachten Sie, dass Server möglicherweise konfiguriert werden müssen, um die Weitergabe dieser Variablen über einige Transporte zu erlauben. Sie wird automatisch weitergegeben, wenn auf lokale Repositories zugegriffen wird (d. h. file:// oder ein Dateisystempfad) sowie über das git://-Protokoll. Für Git-über-HTTP sollte dies in den meisten Konfigurationen automatisch funktionieren, aber siehe die Diskussion in git-http-backend[1]. Für Git-über-SSH muss der SSH-Server möglicherweise so konfiguriert sein, dass Clients diese Variable übergeben dürfen (z. B. durch Verwendung von AcceptEnv GIT_PROTOCOL mit OpenSSH).

Diese Konfiguration ist optional. Wenn die Variable nicht weitergegeben wird, greifen Clients auf das ursprüngliche "v0"-Protokoll zurück (können aber einige Leistungsverbesserungen oder Funktionen verpassen). Diese Variable betrifft derzeit nur Klone und Abrufe; sie wird noch nicht für Pushes verwendet (könnte aber in Zukunft verwendet werden).

GIT_OPTIONAL_LOCKS

Wenn diese boolesche Umgebungsvariable auf false gesetzt ist, schließt Git jede angeforderte Operation ab, ohne optionale Unteroperationen durchzuführen, die eine Sperre erfordern. Dies verhindert beispielsweise, dass git status als Nebeneffekt den Index aktualisiert. Dies ist nützlich für im Hintergrund laufende Prozesse, die keine Sperrkonflikte mit anderen Operationen auf dem Repository verursachen möchten. Standardmäßig ist der Wert 1.

GIT_REDIRECT_STDIN
GIT_REDIRECT_STDOUT
GIT_REDIRECT_STDERR

Nur Windows: Ermöglicht die Umleitung der Standard-Input-/Output-/Error-Handles auf Pfade, die durch die Umgebungsvariablen angegeben werden. Dies ist besonders nützlich in Multi-Thread-Anwendungen, bei denen der kanonische Weg, Standard-Handles über CreateProcess() zu übergeben, keine Option ist, da dies erfordert, dass die Handles als vererbbar markiert werden (und folglich würden **alle** erzeugten Prozesse sie erben, was reguläre Git-Operationen blockieren könnte). Der primäre Verwendungszweck ist die Verwendung von Named Pipes für die Kommunikation (z. B. \\.\pipe\my-git-stdin-123).

Zwei spezielle Werte werden unterstützt: off schließt einfach den entsprechenden Standard-Handle, und wenn GIT_REDIRECT_STDERR 2>&1 ist, wird Standard-Error auf denselben Handle wie Standard-Output umgeleitet.

GIT_PRINT_SHA1_ELLIPSIS (veraltet)

Wenn auf yes gesetzt, wird ein Ellipsenzeichen nach einem (abgekürzten) SHA-1-Wert ausgegeben. Dies wirkt sich auf die Anzeige von getrennten HEADs (git-checkout[1]) und die rohe Diff-Ausgabe (git-diff[1]) aus. Das Ausgeben eines Ellipsenzeichens in den genannten Fällen gilt nicht mehr als ausreichend und die Unterstützung dafür wird voraussichtlich in naher Zukunft (zusammen mit der Variable) entfernt.

GIT_ADVICE

Wenn auf 0 gesetzt, werden alle Ratschlagsnachrichten deaktiviert. Diese Nachrichten sollen menschlichen Benutzern Hinweise geben, die ihnen helfen können, aus problematischen Situationen herauszukommen oder neue Funktionen zu nutzen. Benutzer können einzelne Nachrichten über die Konfigurationsschlüssel advice.* deaktivieren. Diese Nachrichten können für Tools, die Git-Prozesse ausführen, störend sein, daher ist diese Variable verfügbar, um die Nachrichten zu deaktivieren. (Die globale Option --no-advice ist ebenfalls verfügbar, aber alte Git-Versionen können fehlschlagen, wenn diese Option nicht verstanden wird. Die Umgebungsvariable wird von Git-Versionen, die sie nicht verstehen, ignoriert.)

Diskussion

Mehr Details zu den folgenden Punkten finden Sie im Kapitel "Git-Konzepte" des Benutzerhandbuchs und im gitcore-tutorial[7].

Ein Git-Projekt besteht normalerweise aus einem Arbeitsverzeichnis mit einem ".git"-Unterverzeichnis auf oberster Ebene. Das .git-Verzeichnis enthält unter anderem eine komprimierte Objektdatenbank, die die vollständige Historie des Projekts darstellt, eine "Index"-Datei, die diese Historie mit dem aktuellen Inhalt des Arbeitsbaums verknüpft, und benannte Zeiger auf diese Historie wie Tags und Branch-Heads.

Die Objektdatenbank enthält Objekte von drei Haupttypen: Blobs, die Dateidaten enthalten; Trees, die auf Blobs und andere Trees verweisen, um Verzeichnishierarchien aufzubauen; und Commits, die jeweils auf einen einzelnen Tree und eine Anzahl von Eltern-Commits verweisen.

Der Commit, äquivalent zu dem, was andere Systeme "Changeset" oder "Version" nennen, repräsentiert einen Schritt in der Projektgeschichte, und jeder Elternteil repräsentiert einen unmittelbar vorausgehenden Schritt. Commits mit mehr als einem Elternteil repräsentieren Merges von unabhängigen Entwicklungslinien.

Alle Objekte werden nach dem SHA-1-Hash ihres Inhalts benannt, normalerweise als Zeichenkette von 40 Hexadezimalziffern geschrieben. Solche Namen sind global eindeutig. Die gesamte Historie bis zu einem Commit kann durch die Signatur nur dieses Commits verbürgt werden. Ein vierter Objekttyp, der Tag, ist für diesen Zweck vorgesehen.

Bei der ersten Erstellung werden Objekte in einzelnen Dateien gespeichert, können aber später aus Effizienzgründen zu "Pack-Dateien" komprimiert werden.

Benannte Zeiger namens Refs markieren interessante Punkte in der Historie. Ein Ref kann den SHA-1-Namen eines Objekts oder den Namen eines anderen Refs enthalten (letzteres wird als "symbolischer Ref" bezeichnet). Refs mit Namen, die mit refs/head/ beginnen, enthalten den SHA-1-Namen des letzten Commits (oder "Head") eines sich entwickelnden Branches. SHA-1-Namen von Tags von Interesse werden unter refs/tags/ gespeichert. Ein symbolischer Ref namens HEAD enthält den Namen des aktuell ausgecheckten Branches.

Die Indexdatei wird mit einer Liste aller Pfade und für jeden Pfad mit einem Blob-Objekt und einer Reihe von Attributen initialisiert. Das Blob-Objekt repräsentiert den Inhalt der Datei zum Zeitpunkt des Heads des aktuellen Branches. Die Attribute (letzte Änderungszeit, Größe usw.) werden aus der entsprechenden Datei im Arbeitsbaum übernommen. Nachfolgende Änderungen am Arbeitsbaum können durch den Vergleich dieser Attribute gefunden werden. Der Index kann mit neuem Inhalt aktualisiert werden, und neue Commits können aus dem im Index gespeicherten Inhalt erstellt werden.

Der Index ist auch in der Lage, mehrere Einträge (sogenannte "Stages") für einen gegebenen Pfadnamen zu speichern. Diese Stages werden verwendet, um die verschiedenen nicht zusammengeführten Versionen einer Datei zu halten, wenn ein Merge im Gange ist.

SICHERHEIT

Einige Konfigurationsoptionen und Hook-Dateien können dazu führen, dass Git beliebige Shell-Befehle ausführt. Da Konfiguration und Hooks nicht mit git clone kopiert werden, ist es im Allgemeinen sicher, entfernte Repositories mit nicht vertrauenswürdigem Inhalt zu klonen, sie mit git log zu inspizieren und so weiter.

Es ist jedoch nicht sicher, Git-Befehle in einem .git-Verzeichnis (oder dem Arbeitsbaum, der es umgibt) auszuführen, wenn dieses .git-Verzeichnis selbst aus einer nicht vertrauenswürdigen Quelle stammt. Die Befehle in seiner Konfiguration und seinen Hooks werden wie üblich ausgeführt.

Standardmäßig weigert sich Git auszuführen, wenn das Repository jemand anderem als dem Benutzer gehört, der den Befehl ausführt. Siehe den Eintrag für safe.directory in git-config[1]. Obwohl dies Ihnen in einer Multi-User-Umgebung helfen kann, beachten Sie, dass Sie auch nicht vertrauenswürdige Repositories erwerben können, die Ihnen gehören (z. B. wenn Sie eine Zip-Datei oder ein Tarball aus einer nicht vertrauenswürdigen Quelle extrahieren). In solchen Fällen müssten Sie das nicht vertrauenswürdige Repository zuerst "sanitisieren".

Wenn Sie ein nicht vertrauenswürdiges .git-Verzeichnis haben, sollten Sie es zuerst mit git clone --no-local klonen, um eine saubere Kopie zu erhalten. Git schränkt zwar die Menge der Optionen und Hooks ein, die von upload-pack ausgeführt werden, was die Serverseite eines Klons oder Abrufs behandelt, aber bedenken Sie, dass die Angriffsfläche für upload-pack groß ist, daher birgt dies ein gewisses Risiko. Am sichersten ist es, das Repository als privilegierter Benutzer bereitzustellen (entweder über git-daemon[1], ssh oder unter Verwendung anderer Tools zum Ändern von Benutzer-IDs). Siehe die Diskussion im Abschnitt SECURITY von git-upload-pack[1].

WEITERE DOKUMENTATION

Siehe die Referenzen im Abschnitt "Beschreibung", um mit der Verwendung von Git zu beginnen. Das Folgende ist wahrscheinlich mehr Detail als für einen Anfänger notwendig.

Das Kapitel "Git-Konzepte" des Benutzerhandbuchs und gitcore-tutorial[7] bieten beide Einführungen in die zugrunde liegende Git-Architektur.

Siehe gitworkflows[7] für einen Überblick über empfohlene Workflows.

Siehe auch die howto-Dokumente für einige nützliche Beispiele.

Die Interna sind in der Git API-Dokumentation dokumentiert.

Benutzer, die von CVS migrieren, sollten auch gitcvs-migration[7] lesen.

Autoren

Git wurde von Linus Torvalds gestartet und wird derzeit von Junio C Hamano gepflegt. Zahlreiche Beiträge kamen von der Git-Mailingliste <git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary bietet Ihnen eine vollständigere Liste der Mitwirkenden.

Wenn Sie einen Klon von git.git selbst haben, können die Ausgaben von git-shortlog[1] und git-blame[1] Ihnen die Autoren für bestimmte Teile des Projekts anzeigen.

Fehlerberichterstattung

Melden Sie Fehler an die Git-Mailingliste <git@vger.kernel.org>, wo die Entwicklung und Wartung hauptsächlich stattfindet. Sie müssen nicht auf der Liste abonniert sein, um eine Nachricht dorthin zu senden. Sehen Sie sich das Listenarchiv unter https://lore.kernel.org/git für frühere Fehlerberichte und andere Diskussionen an.

Sicherheitsrelevante Probleme sollten vertraulich an die Git-Sicherheits-Mailingliste <git-security@googlegroups.com> gemeldet werden.

SIEHE AUCH

gittutorial[7], gittutorial-2[7], giteveryday[7], gitcvs-migration[7], gitglossary[7], gitcore-tutorial[7], gitcli[7], Das Git-Benutzerhandbuch, gitworkflows[7]

GIT

Teil der git[1] Suite