Man » Git-Handbuch online - detaillierte Online-Dokumentation für die Git-Manpage

🌍 ☰

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

DESCRIPTION

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

Lesen Sie gittutorial(7), um loszulegen, und dann giteveryday(7) für eine nützliche Mindestmenge von Befehlen. Das Git-Benutzerhandbuch[1] bietet eine detailliertere Einführung.

Nachdem Sie die grundlegenden Konzepte verstanden haben, können Sie zu dieser Seite zurückkehren, um mehr über die Befehle zu erfahren, die Git bietet. Sie können mehr über einzelne Git-Befehle erfahren, indem Sie „git help command“ verwenden. Die gitcli(7)-Manpage gibt Ihnen einen Überblick über die Syntax der Befehlszeilenbefehle.

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

OPTIONS

-v, --version

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

Diese Option wird intern in git version ... konvertiert und akzeptiert die gleichen Optionen wie der Befehl git-version(1). Wenn --help ebenfalls angegeben ist, hat dies Vorrang vor --version.

-h, --help

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

Es stehen weitere Optionen zur Verfügung, um zu steuern, wie die Manpage angezeigt wird. Weitere Informationen finden Sie in git-help(1), da git --help ... intern in git help ... konvertiert wird.

-C <path>

Führen Sie den Befehl aus, als wäre Git in <path> anstelle des aktuellen Arbeitsverzeichnisses gestartet worden. Wenn mehrere -C-Optionen angegeben werden, wird jede nachfolgende nicht-absolute -C relativ zum vorherigen -C interpretiert. Wenn vorhanden ist, aber leer ist, z. B. -C "", bleibt das aktuelle Arbeitsverzeichnis unverändert.

Diese Option wirkt sich auf Optionen aus, die einen Pfadnamen erwarten, wie z. B. --git-dir und --work-tree, in dem Sinne, dass ihre Interpretation der Pfadnamen relativ zum durch die Option -C verursachten Arbeitsverzeichnis erfolgt. 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>=<value>

Übergibt einen Konfigurationsparameter an den Befehl. Der angegebene Wert überschreibt die Werte aus den Konfigurationsdateien. wird im gleichen Format erwartet, wie es von git config angezeigt wird (Unterglieder sind durch Punkte getrennt).

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

`--config-env=<name>=<envvar>`

Wie -c <name\>=<value>, gibt eine Konfigurationsvariable <name\> einen Wert, wobei <envvar> der Name einer Umgebungsvariable ist, aus der der Wert abgerufen wird. Im Gegensatz zu -c gibt es keine Abkürzung, um den Wert direkt auf einen leeren String zu setzen; stattdessen muss die Umgebungsvariable selbst auf einen leeren String gesetzt werden. Es ist ein Fehler, wenn <envvar> nicht in der Umgebung existiert. <envvar> darf kein Gleichheitszeichen enthalten, um eine Verwechslung mit <name>, das ein Gleichheitszeichen enthält, zu vermeiden.

Dies ist nützlich für Fälle, in denen Sie temporäre Konfigurationsoptionen an Git übergeben möchten, dies aber auf Betriebssystemen tun, bei denen andere Prozesse Ihre Befehlszeile lesen können (z. B. /proc/self/cmdline), aber nicht Ihre Umgebung (z. B. /proc/self/environ). Dieses Verhalten ist standardmäßig unter Linux, kann aber auf Ihrem System anders sein.

Beachten Sie, dass dies möglicherweise zusätzliche Sicherheit für Variablen wie http.extraHeader bietet, bei denen die sensiblen Informationen Teil des Werts sind, aber nicht z. B. für url.<base>.insteadOf, bei dem die sensiblen Informationen Teil des Schlüssels sein können.

`--exec-path[=<path>]`

Pfad zu dem Verzeichnis, in dem Ihre Git-Kernprogramme installiert sind. Dies kann auch durch Setzen der Umgebungsvariablen GIT_EXEC_PATH gesteuert werden. Wenn kein Pfad angegeben wird, gibt Git die aktuelle Einstellung aus und beendet sich.

`--html-path`

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

`--man-path`

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

`--info-path`

Gibt den Pfad aus, in dem die Info-Dateien, die diese Version von Git dokumentieren, installiert sind, und beendet sich.

`-p, --paginate`

Leitet alle Ausgaben an less weiter (oder, falls festgelegt, $PAGER), wenn die Standardausgabe ein Terminal ist. Dies überschreibt die Konfigurationsoptionen pager.<cmd> (siehe den Abschnitt "Konfigurationsmechanismus" unten).

`-P, --no-pager`

Leitet die Git-Ausgabe nicht an einen Pager weiter.

`--git-dir=<path>`

Legt den Pfad zum Repository (Verzeichnis ".git") fest. Dies kann auch durch Setzen der Umgebungsvariablen GIT_DIR gesteuert werden. Es kann sich um einen absoluten oder relativen Pfad zum aktuellen Arbeitsverzeichnis handeln.

Das Angeben des Speicherorts des ".git"-Verzeichnisses mit dieser Option (oder der Umgebungsvariablen GIT_DIR) deaktiviert die Repository-Erkennung, die versucht, ein Verzeichnis mit einem ".git"-Unterverzeichnis zu finden (was die Art und Weise ist, wie das Repository und die oberste Ebene des Arbeitsbereichs gefunden werden), und teilt Git mit, dass Sie sich auf der obersten Ebene des Arbeitsbereichs befinden. Wenn Sie sich nicht auf der obersten Ebene des Arbeitsbereichs befinden, sollten Sie Git mit der Option --work-tree=<path> (oder der Umgebungsvariablen GIT_WORK_TREE) mitteilen, wo sich die oberste Ebene des Arbeitsbereichs befindet.

Wenn Sie Git einfach so ausführen möchten, als ob es im Verzeichnis <path> gestartet wurde, verwenden Sie git -C <path\>.

--work-tree=<path>
Legen Sie den Pfad zum Arbeitsbereich fest. Dies kann ein absoluter Pfad oder ein Pfad relativ zum
aktuellen Arbeitsverzeichnis sein. Dies kann auch durch Festlegen der Umgebungsvariablen `GIT_WORK_TREE`
und der Konfigurationsvariablen `core.worktree` gesteuert werden (siehe `core.worktree` in `gitconfig(1)`
für eine detailliertere Erläuterung).

--namespace=<path>
Legen Sie den Git-Namensraum fest. Siehe `gitnamespaces(7)` für weitere Informationen. Entspricht dem Festlegen
der Umgebungsvariablen `GIT_NAMESPACE`.

--bare
Behandeln Sie das Repository als ein "bare" Repository. Wenn die Umgebungsvariable `GIT_DIR` nicht gesetzt ist,
wird sie auf das aktuelle Arbeitsverzeichnis gesetzt.

--no-replace-objects
Verwenden Sie keine "replacement refs", um Git-Objekte zu ersetzen. Dies entspricht dem Festlegen der
Umgebungsvariablen `GIT_NO_REPLACE_OBJECTS` mit einem beliebigen Wert. Siehe `git-replace(1)` für weitere
Informationen.

--no-lazy-fetch
Rufen Sie die fehlenden Objekte nicht bei Bedarf vom "promisor remote" ab. Nützlich in Verbindung mit
`git cat-file -e <object\>`, um zu überprüfen, ob das Objekt lokal verfügbar ist. Dies entspricht dem
Festlegen der Umgebungsvariablen `GIT_NO_LAZY_FETCH` auf 1.

--no-optional-locks
Führen Sie keine optionalen Operationen aus, die Sperren erfordern. Dies entspricht dem Festlegen von
`GIT_OPTIONAL_LOCKS` auf 0.

--no-advice
Deaktivieren Sie alle Hinweise, die ausgegeben werden.

--literal-pathspecs
Behandeln Sie Pfadspezifikationen wörtlich (d. h. keine Globbing- oder Pfadspezifikationsmagie). Dies entspricht
dem Festlegen der Umgebungsvariablen `GIT_LITERAL_PATHSPECS` auf 1.

--glob-pathspecs
Fügen Sie allen Pfadspezifikationen die Magie "glob" hinzu. Dies entspricht dem Festlegen der Umgebungsvariablen
`GIT_GLOB_PATHSPECS` auf 1. Das Deaktivieren des Globbings für einzelne Pfadspezifikationen kann mithilfe der
Pfadspezifikationsmagie `:(literal)` erfolgen.

--noglob-pathspecs
Fügen Sie allen Pfadspezifikationen die Magie "literal" hinzu. Dies entspricht dem Festlegen der Umgebungsvariablen
`GIT_NOGLOB_PATHSPECS` auf 1. Das Aktivieren des Globbings für einzelne Pfadspezifikationen kann mithilfe der
Pfadspezifikationsmagie `:(glob)` erfolgen.

--icase-pathspecs
Fügen Sie allen Pfadspezifikationen die Magie "icase" hinzu. Dies entspricht dem Festlegen der Umgebungsvariablen
`GIT_ICASE_PATHSPECS` auf 1.

--list-cmds=<group>[,<group>...]
Listen Sie 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` (interne Befehle, die
`parse-options` verwenden), `main` (alle Befehle im Verzeichnis `libexec`), `others` (alle anderen Befehle in
`$PATH`, die das Präfix `git-` haben), `list-<category>` (siehe Kategorien in `command-list.txt`),
`nohelpers` (Hilfsbefehle ausschließen), `alias` und `config` (Befehlsliste aus der Konfigurationsvariablen
`completion.commands` abrufen).

--attr-source=<tree-ish>
Lesen Sie `gitattributes` aus `<tree-ish>` anstelle des Arbeitsbereichs. Siehe `gitattributes(5)`. Dies entspricht
dem Festlegen der Umgebungsvariablen `GIT_ATTR_SOURCE`.

GIT-BEFEHLE

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

HOCHWERTIGE BEFEHLE (PORZELLAN)

Wir teilen die Porzellan-Befehle in die Hauptbefehle und einige zusätzliche Benutzer-Tools auf.

Haupt-Porzellanbefehle

git-add(1)

Fügt den Inhalt einer Datei zum Index hinzu.

git-am(1)

Wendet eine Reihe von Patches aus einem Postfach an.

git-archive(1)

Erstellt ein Archiv von Dateien aus einem bestimmten Baum.

git-backfill(1)

Lädt fehlende Objekte in einem teilweisen Klon herunter.

git-bisect(1)

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

git-branch(1)

Listet, erstellt oder löscht Branches.

git-bundle(1)

Verschiebt Objekte und Referenzen durch Archivierung.

git-checkout(1)

Wechselt zwischen Branches oder stellt Dateien im Arbeitsbereich wieder her.

git-cherry-pick(1)

Wendet die Änderungen an, die von einigen vorhandenen Commits eingeführt wurden.

git-citool(1)

Grafische Alternative zu git-commit.

git-clean(1)

Entfernt nicht verfolgte Dateien aus dem Arbeitsbereich.

git-clone(1)

Kopiert ein Repository in ein neues Verzeichnis.

git-commit(1)

Speichert Änderungen im Repository.

git-describe(1)

Gibt einem Objekt einen für Menschen lesbaren Namen basierend auf einer verfügbaren Referenz.

git-diff(1)

Zeigt Änderungen zwischen Commits, einem Commit und dem Arbeitsbereich usw. an.

git-fetch(1)

Lädt Objekte und Referenzen aus einem anderen Repository herunter.

git-format-patch(1)

Bereitet Patches für die Übermittlung per E-Mail 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 vorhandenes neu.

git-log(1)

Zeigt Commit-Protokolle an.

git-maintenance(1)

Führt Aufgaben aus, um Git-Repository-Daten zu optimieren.

git-merge(1)

Führt zwei oder mehr Entwicklungshistorien zusammen.

git-mv(1)

Verschiebt oder benennt eine Datei, ein Verzeichnis oder ein symbolisches Link um.

git-notes(1)

Fügt Objekt-Notizen hinzu oder untersucht sie.

git-pull(1)

Ruft von einem anderen Repository oder einem lokalen Branch ab und integriert sie.

git-push(1)

Aktualisiert Remote-Referenzen zusammen mit den zugehörigen Objekten.

git-range-diff(1)

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

git-rebase(1)

Wendet Commits erneut auf einer anderen Basis an.

git-reset(1)

Setzt den aktuellen HEAD auf den angegebenen Zustand zurück.

git-restore(1)

Stellt Dateien im Arbeitsbereich wieder her.

git-revert(1)

Macht einige vorhandene Commits rückgängig.

git-rm(1)

Entfernt Dateien aus dem Arbeitsbereich und aus 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 Arbeitsbereich auf eine Teilmenge der verfolgten Dateien.

git-stash(1)

Speichert die Änderungen in einem "dirty" Arbeitsverzeichnis zwischen.

git-status(1)

Zeigt den Status des Arbeitsbereichs an.

git-submodule(1)

Initialisiert, aktualisiert oder untersucht Submodule.

git-switch(1)

Wechselt zwischen Branches.

git-tag(1)

Erstellt, listet, löscht oder verifiziert ein Tag-Objekt, das mit GPG signiert ist.

git-worktree(1)

Verwaltet mehrere Arbeitsbereiche.

gitk(1)

Der Git-Repository-Browser.

scalar(1)

Ein Tool zum Verwalten großer Git-Repositories.

Zusätzliche Befehle

Manipulatoren:

git-config(1)

Ruft Repository- oder globale Optionen ab und legt sie fest.

git-fast-export(1)

Git-Datenexporteur.

git-fast-import(1)
Backend für schnelle Git-Datenimporte.

git-filter-branch(1)
Ändern von Branches.

git-mergetool(1)
Ausführen von Tools zur Konfliktlösung, um Merge-Konflikte zu beheben.

git-pack-refs(1)
Packen von Heads und Tags für einen effizienten Repository-Zugriff.

git-prune(1)
Entfernen aller unerreichbaren Objekte aus der Objektdatenbank.

git-reflog(1)
Verwalten von Reflog-Informationen.

git-refs(1)
Low-Level-Zugriff auf Refs.

git-remote(1)
Verwalten einer Reihe von verfolgten Repositories.

git-repack(1)
Packen von nicht gepackten Objekten in einem Repository.

git-replace(1)
Erstellen, Auflisten, Löschen von Refs zum Ersetzen von Objekten.

Interrogatoren:

git-annotate(1)
Kommentieren von Dateizeilen mit Commit-Informationen.

git-blame(1)
Anzeigen, welche Revision und welcher Autor jede Zeile einer Datei zuletzt geändert haben.

git-bugreport(1)
Sammeln von Informationen, damit der Benutzer einen Fehlerbericht einreichen kann.

git-count-objects(1)
Zählen der Anzahl der nicht gepackten Objekte und ihres Speicherplatzverbrauchs.

git-diagnose(1)
Erstellen eines ZIP-Archivs mit Diagnoseinformationen.

git-difftool(1)
Anzeigen von Änderungen mit gängigen Diff-Tools.

git-fsck(1)
Überprüft die Konnektivität und Gültigkeit der Objekte in der Datenbank.

git-help(1)
Anzeigen von Hilfsinformationen zu Git.

git-instaweb(1)
Durchsuchen Sie Ihr Arbeitsrepository sofort in gitweb.

git-merge-tree(1)
Durchführen eines Merges, ohne den Index oder den Arbeitsbereich zu berühren.

git-rerere(1)
Wiederverwenden der aufgezeichneten Auflösung von konfliktbehafteten Merges.

git-show-branch(1)
Anzeigen von Branches und ihren Commits.

git-verify-commit(1)
Überprüfen der GPG-Signatur von Commits.

git-verify-tag(1)
Überprüfen der GPG-Signatur von Tags.

git-version(1)
Anzeigen von Versionsinformationen zu Git.

git-whatchanged(1)
Anzeigen von Logs mit den Unterschieden, die jeder Commit einführt.

gitweb(1)
Git-Webschnittstelle (Web-Frontend für Git-Repositories).

Interaktion mit anderen

Diese Befehle dienen der Interaktion mit fremden SCMs und mit anderen Personen per E-Mail-Patch.

git-archimport(1)
Importieren eines GNU Arch-Repositorys in Git.

git-cvsexportcommit(1)
Exportieren eines einzelnen Commits in ein CVS-Checkout.

git-cvsimport(1)
Rettung Ihrer Daten aus einem anderen SCM, das andere Leute lieben, aber hassen.

git-cvsserver(1)
Ein CVS-Server-Emulator für Git.

git-imap-send(1)
Senden einer Sammlung von Patches von stdin an einen IMAP-Ordner.

git-p4(1)
Importieren von und Übermitteln an Perforce-Repositories.

git-quiltimport(1)
Anwenden eines Quilt-Patchsets auf den aktuellen Branch.

git-request-pull(1)
Generieren einer Zusammenfassung ausstehender Änderungen.

git-send-email(1)
Senden einer Sammlung von Patches per E-Mail.

git-svn(1)
Bidirektionaler Betrieb zwischen einem Subversion-Repository und Git.

Zurücksetzen, Wiederherstellen und Rückgängigmachen

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

git-revert(1) dient dazu, einen neuen Commit zu erstellen, der die Änderungen anderer Commits rückgängig macht.

git-restore(1) dient dazu, Dateien im Arbeitsbereich entweder aus dem Index oder aus einem anderen
Commit wiederherzustellen. Dieser Befehl aktualisiert nicht Ihren Branch. Der Befehl kann auch verwendet werden, um
Dateien im Index aus einem anderen Commit wiederherzustellen.

git-reset(1) dient dazu, Ihren Branch zu aktualisieren und die Spitze zu verschieben, um Commits
hinzuzufügen oder aus dem Branch zu entfernen. Diese Operation ändert den Commit-Verlauf.

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

NIEDRIGLIEGENDE BEFEHLE (PLUMBING)

Obwohl Git eine eigene Porcelain-Schicht enthält, sind seine niedrigliegenden Befehle ausreichend, um die Entwicklung alternativer Porcelains zu unterstützen. Entwickler solcher Porcelains sollten sich zunächst mit git-update-index(1) und git-read-tree(1) vertraut machen.

Die Schnittstelle (Eingabe, Ausgabe, Optionssatz und Semantik) dieser niedrigliegenden Befehle ist viel stabiler als die der Porcelain-Befehle, da diese Befehle hauptsächlich für die Verwendung in Skripten gedacht sind. Die Schnittstelle der Porcelain-Befehle kann sich andererseits ändern, um das Benutzererlebnis zu verbessern.

Die folgende Beschreibung unterteilt die niedrigliegenden Befehle in Befehle, die Objekte manipulieren (im Repository, Index und Arbeitsverzeichnis), Befehle, die Objekte abfragen und vergleichen, und Befehle, die Objekte und Referenzen zwischen Repositories verschieben.

Manipulationsbefehle

git-apply(1)
Wendet einen Patch auf Dateien und/oder auf den Index an.

git-checkout-index(1)
Kopiert Dateien vom Index in das Arbeitsverzeichnis.

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-Index-Datei für ein vorhandenes gepacktes Archiv.

git-merge-file(1)
Führt eine Drei-Wege-Datei-Zusammenführung durch.

git-merge-index(1)
Führt eine Zusammenführung für Dateien durch, die eine Zusammenführung benötigen.

git-mktag(1)
Erstellt ein Tag-Objekt mit zusätzlicher Validierung.

git-mktree(1)
Erstellt ein Baum-Objekt aus ls-tree-formatierter 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 enthalten sind.

git-read-tree(1)
Liest Baum-Informationen in den Index ein.

git-replay(1)
EXPERIMENTELL: Spielt Commits auf einer neuen Basis ab, funktioniert auch mit Bare-Repos.

git-symbolic-ref(1)
Liest, ändert und löscht symbolische Referenzen.

git-unpack-objects(1)
Entpackt Objekte aus einem gepackten Archiv.

git-update-index(1)
Registriert Dateiinhalte im Arbeitsverzeichnis im Index.

git-update-ref(1)
Aktualisiert die in einer Referenz gespeicherte Objektbezeichnung sicher.

git-write-tree(1)
Erstellt ein Baum-Objekt aus dem aktuellen Index.

Abfragebefehle

git-cat-file(1)
Stellt den Inhalt oder Details von Repository-Objekten bereit.

git-cherry(1)
Findet Commits, die noch nicht in den Upstream übernommen wurden.

git-diff-files(1)
Vergleicht Dateien im Arbeitsverzeichnis und im Index.

git-diff-index(1)
Vergleicht einen Baum mit dem Arbeitsverzeichnis oder Index.

git-diff-pairs(1)
Vergleicht den Inhalt und den Modus der angegebenen Blob-Paare.

git-diff-tree(1)
Vergleicht den Inhalt und den Modus der über zwei Baum-Objekte gefundenen Blobs.

git-for-each-ref(1)
Gibt Informationen zu jeder Referenz aus.

git-for-each-repo(1)
Führt einen Git-Befehl auf einer Liste von Repositories aus.

git-get-tar-commit-id(1)
Extrahiert die Commit-ID aus einem mit git-archive erstellten Archiv.

git-ls-files(1)
Zeigt Informationen über Dateien im Index und im Arbeitsbereich an.

git-ls-remote(1)
Listet Referenzen in einem Remote-Repository auf.

git-ls-tree(1)
Listet den Inhalt eines Baumobjekts auf.

git-merge-base(1)
Findet so gute gemeinsame Vorfahren wie möglich für einen Merge.

git-name-rev(1)
Findet symbolische Namen für gegebene Revisionsstände.

git-pack-redundant(1)
Findet redundante Pack-Dateien.

git-rev-list(1)
Listet Commit-Objekte in umgekehrter chronologischer Reihenfolge auf.

git-rev-parse(1)
Wählt Parameter aus und modifiziert sie.

git-show-index(1)
Zeigt den gepackten Archivindex an.

git-show-ref(1)
Listet Referenzen in einem lokalen Repository auf.

git-unpack-file(1)
Erstellt eine temporäre Datei mit dem Inhalt eines Blob-Objekts.

git-var(1)
Zeigt eine Git-logische Variable an.

git-verify-pack(1)
Validiert gepackte Git-Archivdateien.

Im Allgemeinen verändern die Befehle zur Informationsabfrage keine Dateien im Arbeitsbereich.

Synchronisierung von Repositories

git-daemon(1)
Ein sehr einfacher Server für Git-Repositories.

git-fetch-pack(1)
Empfängt fehlende Objekte von einem anderen Repository.

git-http-backend(1)
Serverseitige Implementierung von Git über HTTP.

git-send-pack(1)
Überträgt Objekte über das Git-Protokoll zu einem anderen Repository.

git-update-server-info(1)
Aktualisiert die Hilfsdatei, um einfachen Servern zu helfen.

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

git-http-fetch(1)
Lädt Daten von einem Remote-Git-Repository über HTTP herunter.

git-http-push(1)
Überträgt Objekte über HTTP/DAV zu einem anderen Repository.

git-receive-pack(1)
Empfängt die Daten, die in das Repository übertragen werden.

git-shell(1)
Beschränkte Login-Shell für den Git-Only-SSH-Zugriff.

git-upload-archive(1)
Sendet ein Archiv zurück an git-archive.

git-upload-pack(1)
Sendet gepackte Objekte zurück an git-fetch-pack.

Interne Hilfsbefehle

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

git-check-attr(1)
Zeigt Informationen über gitattributes an.

git-check-ignore(1)
Debuggt gitignore-/exclude-Dateien.

git-check-mailmap(1)
Zeigt kanonische Namen und E-Mail-Adressen von Kontakten an.

git-check-ref-format(1)
Stellt sicher, dass ein Referenzname wohlgeformt ist.

git-column(1)
Zeigt Daten in Spalten an.

git-credential(1)
Ruft Benutzeranmeldeinformationen ab und speichert sie.

git-credential-cache(1)
Hilfsprogramm zum temporären Speichern von Passwörtern im Speicher.

git-credential-store(1)
Hilfsprogramm zum Speichern von Anmeldeinformationen auf der Festplatte.

git-fmt-merge-msg(1)
Erstellt eine Merge-Commit-Nachricht.

git-hook(1)
Führt Git-Hooks aus.

git-interpret-trailers(1)
Fügt strukturierte Informationen in Commit-Nachrichten hinzu oder analysiert sie.

git-mailinfo(1)
Extrahiert Patch- und Autorendaten aus einer einzelnen E-Mail-Nachricht.

git-mailsplit(1)
Einfaches UNIX mbox-Splitterprogramm.

git-merge-one-file(1)
Das Standard-Hilfsprogramm zur Verwendung mit git-merge-index.

git-patch-id(1)
Berechnet eine eindeutige ID für einen Patch.

git-sh-i18n(1)
Git's i18n-Setup-Code für Shell-Skripte.

git-sh-setup(1)
Gemeinsamer Git-Shell-Skript-Setup-Code.

git-stripspace(1)
Entfernt unnötige Leerzeichen.

GUIDES

Die folgenden Dokumentationsseiten sind Anleitungen zu Git-Konzepten.

gitcore-tutorial(7)
Ein Git-Kern-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ützliches, minimales Befehlssatz für den täglichen Gebrauch von Git.

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 Remote-Repositories.

gitsubmodules(7)
Ein Repository in ein anderes einbinden.

gittutorial(7)
Eine Einführung in Git.

gittutorial-2(7)
Eine Einführung in Git: Teil zwei.

gitworkflows(7)
Eine Übersicht über empfohlene Workflows mit Git.

REPOSITORY-, BEFEHLS- UND DATEISCHNITTSTELLEN

Diese Dokumentation behandelt Repository- und Befehlsschnittstellen, mit denen Benutzer voraussichtlich direkt interagieren. Siehe --user-formats in git-help(1) für weitere Details zu den Kriterien.

gitattributes(5)
Definieren von Attributen pro Pfad.

gitcli(7)
Git-Befehlszeilenschnittstelle und Konventionen.

githooks(5)
Von Git verwendete Hooks.

gitignore(5)
Gibt absichtlich nicht verfolgte Dateien an, die ignoriert werden sollen.

gitmailmap(5)
Zuordnung von Autoren-/Commit-Namen und/oder E-Mail-Adressen.

gitmodules(5)
Definieren von Submodul-Eigenschaften.

gitrepository-layout(5)
Git-Repository-Layout.

gitrevisions(7)
Angabe von Revisionen und Bereichen für Git.

DATEIFORMATE, PROTOKOLLE UND ANDERE ENTWICKLERSCHNITTSTELLEN

Diese Dokumentation behandelt Dateiformate, drahtgebundene 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-Indexformat.

gitformat-pack(5)
Git-Packformat.

gitformat-signature(5)
Git-kryptografische Signaturformate.

gitprotocol-capabilities(5)
Protokoll-V0- und V1-Funktionen.

gitprotocol-common(5)
Gemeinsame Elemente verschiedener Protokolle.

gitprotocol-http(5)
Git-HTTP-basierte Protokolle.

gitprotocol-pack(5)
Wie Pakete über den Draht übertragen werden.

gitprotocol-v2(5)
Git-Drahtprotokoll, Version 2.

KONFIGURATIONSMECHANISMUS

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

#
# Ein '#' oder ';' Zeichen kennzeichnet einen Kommentar.
#

; Core-Variablen
[core]
; Nicht den Dateimodus vertrauen
filemode = false

; Benutzeridentität
[user]
name = "Junio C Hamano"
email = "_"

Verschiedene Befehle lesen aus der Konfigurationsdatei und passen ihre Ausführung entsprechend an. Siehe git-config(1) für eine Liste und weitere Details zum Konfigurationsmechanismus.

TERMINOLOGIE DER IDENTIFIKATOREN

<object>
Kennzeichnet den Objektnamen für jeden Objekttyp.

<blob>
Kennzeichnet ein Blob-Objekt.

<tree>
Kennzeichnet ein Baum-Objekt.

<commit>
Kennzeichnet ein Commit-Objekt.

<tree-ish>
Kennzeichnet ein Baum-, Commit- oder Tag-Objekt. Ein Befehl, der ein <tree-ish>-Argument annimmt,
möchte letztendlich auf ein <tree>-Objekt operieren, dereferenziert aber automatisch <commit>- und
<tag>-Objekte, die auf ein <tree> zeigen.

<commit-ish>

Bezeichnet den Namen eines Commit- oder Tag-Objekts. Ein Befehl, der ein -Argument akzeptiert, möchte letztendlich auf einem -Objekt operieren, dereferenziert aber automatisch -Objekte, die auf ein zeigen.

<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 Stamm des Baumstruktur, die GIT_INDEX_FILE beschreibt.

SYMBOLISCHE IDENTIFIKATOREN

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

HEAD
bezeichnet den Kopf des aktuellen Zweigs.

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

Für eine vollständige Liste der Möglichkeiten zur Schreibweise von Objektnamen siehe den Abschnitt „SPECIFYING REVISIONS“ in gitrevisions(7).

DATEI-/VERZEICHNISSTRUKTUR

Siehe das Dokument gitrepository-layout(5).

Lesen Sie githooks(5) für weitere Details zu jedem Hook.

Höherwertige SCMs können zusätzliche Informationen in $GIT_DIR bereitstellen und verwalten.

TERMINOLOGIE

Siehe gitglossary(7).

UMGEBUNGSVARIABLEN

Verschiedene Git-Befehle berücksichtigen Umgebungsvariablen und ändern ihr Verhalten. Die Umgebungsvariablen, die als „Boolesch“ gekennzeichnet sind, übernehmen ihre Werte auf die gleiche Weise 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 setzt Git, falls nicht gesetzt, eine Prozessumgebungsvariable auf: $HOMEDRIVE$HOMEPATH, falls sowohl $HOMEDRIVE als auch $HOMEPATH vorhanden sind; andernfalls $USERPROFILE, falls $USERPROFILE vorhanden ist.

Das Git-Repository

Diese Umgebungsvariablen gelten für alle Kern-Git-Befehle. Hinweis: Es ist erwähnenswert, dass sie von SCMs verwendet oder überschrieben werden können, die auf Git aufbauen, daher ist Vorsicht geboten, wenn Sie ein externes Frontend verwenden.

GIT_INDEX_FILE

Diese Umgebungsvariable gibt eine alternative Indexdatei an. Wenn nicht angegeben, wird standardmäßig $GIT_DIR/index verwendet.

GIT_INDEX_VERSION

Diese Umgebungsvariable gibt an, welche Indexversion beim Schreiben der Indexdatei verwendet wird. Sie wirkt sich nicht auf vorhandene Indexdateien aus. 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 gemeinsam genutzten, schreibgeschützten Verzeichnissen archiviert werden. Diese Variable gibt eine durch „:“ getrennte (unter Windows durch „;“ getrennte) Liste von Git-Objektverzeichnissen an, in denen nach Git-Objekten gesucht werden kann. Neue Objekte werden nicht in diese Verzeichnisse geschrieben.

Einträge, die mit " (doppeltes Anführungszeichen) beginnen, werden als C-ähnliche Pfade mit Anführungszeichen interpretiert, wobei die führenden und nachfolgenden doppelten Anführungszeichen entfernt und Backslash-Escape-Sequenzen berücksichtigt werden. Zum Beispiel hat der Wert "path-with-\"-and-:-in-it":vanilla-path 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 Standardwerts .git für die Basis des Repositorys verwendet werden soll. Die Kommandozeilenoption --git-dir setzt diesen Wert ebenfalls.

GIT_WORK_TREE

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

GIT_NAMESPACE

Setzt den Git-Namensraum; siehe gitnamespaces(7) für weitere Informationen. Die Kommandozeilenoption --namespace setzt diesen Wert ebenfalls.

GIT_CEILING_DIRECTORIES

Dies sollte eine durch Doppelpunkte getrennte Liste von absoluten Pfaden sein. Wenn dies gesetzt ist, ist es eine Liste von Verzeichnissen, in die Git beim Suchen nach einem Repository-Verzeichnis nicht nach oben wechseln soll (nützlich zum Ausschließen von langsam ladenden Netzwerkverzeichnissen). Es schließt weder das aktuelle Arbeitsverzeichnis noch ein über GIT_DIR in der Befehlszeile oder in der Umgebung gesetztes Verzeichnis aus. Normalerweise muss Git die Einträge in dieser Liste lesen und alle darin möglicherweise vorhandenen symbolischen Links auflösen, um sie mit dem aktuellen Verzeichnis zu vergleichen. Wenn selbst dieser Zugriff jedoch langsam ist, können Sie einen leeren Eintrag in die Liste einfügen, um Git mitzuteilen, dass die nachfolgenden Einträge keine symbolischen Links 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 enthält, versucht Git, ein solches Verzeichnis in den übergeordneten Verzeichnissen zu finden, um die Spitze des Arbeitsbaums zu finden, aber standardmäßig wird es nicht über Dateisystemgrenzen hinweg gesucht. Diese boolesche Umgebungsvariable kann auf "true" gesetzt werden, um Git mitzuteilen, dass es nicht an Dateisystemgrenzen anhalten soll. Wie GIT_CEILING_DIRECTORIES hat dies keinen Einfluss auf ein explizit über GIT_DIR oder über die Befehlszeile festgelegtes Repository-Verzeichnis.

GIT_COMMON_DIR

Wenn diese Variable auf einen Pfad gesetzt ist, werden nicht-Arbeitsbaumbedingte Dateien, die normalerweise in $GIT_DIR gespeichert werden, stattdessen aus diesem Pfad abgerufen. Arbeitsbaumspezifische Dateien wie HEAD oder der Index werden aus $GIT_DIR abgerufen. Siehe gitrepository-layout(5) und git-worktree(1) für weitere Informationen. Diese Variable hat eine geringere Priorität als andere Pfadvariablen wie GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY usw.

GIT_DEFAULT_HASH

Wenn diese Variable gesetzt ist, wird der Standard-Hash-Algorithmus für neue Repositorys auf diesen Wert gesetzt. Dieser Wert wird beim Klonen ignoriert, und die Einstellung des Remote-Repositorys wird immer verwendet. Der Standardwert 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 Repositorys auf diesen Wert gesetzt. Der Standardwert ist "files". Siehe --ref-format in git-init(1).

Git-Commits

GIT_AUTHOR_NAME

Der menschenlesbare Name, der für die Autoren-Identität beim Erstellen von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Einstellungen user.name und author.name in der Konfiguration.

GIT_AUTHOR_EMAIL

Die E-Mail-Adresse, die für die Autorenidentität beim Erstellen von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Einstellungen user.email und author.email in der Konfiguration.

GIT_AUTHOR_DATE

Das Datum, das für die Autorenidentität beim Erstellen von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Siehe git-commit(1) für gültige Formate.

GIT_COMMITTER_NAME

Der lesbare Name, der für die Committer-Identität beim Erstellen von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Einstellungen user.name und committer.name in der Konfiguration.

GIT_COMMITTER_EMAIL

Die E-Mail-Adresse, die für die Committer-Identität beim Erstellen von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Überschreibt die Einstellungen user.email und committer.email in der Konfiguration.

GIT_COMMITTER_DATE

Das Datum, das für die Committer-Identität beim Erstellen von Commit- oder Tag-Objekten oder beim Schreiben von Reflogs verwendet wird. Siehe git-commit(1) für gültige Formate.

EMAIL

Die E-Mail-Adresse, die für die Autoren- und Committer-Identitäten verwendet wird, wenn keine andere relevante Umgebungsvariable oder Konfigurationseinstellung festgelegt ist.

Git-Diffs

GIT_DIFF_OPTS

Die einzige gültige Einstellung ist --unified=? oder -u=?, um die Anzahl der Kontextzeilen festzulegen, die angezeigt werden, wenn ein einheitlicher Diff erstellt wird. Dies hat Vorrang vor allen -U- oder --unified-Optionen, die in der Git-Diff-Befehlszeile übergeben werden.

GIT_EXTERNAL_DIFF

Wenn die Umgebungsvariable GIT_EXTERNAL_DIFF gesetzt ist, wird das durch diese benannte Programm aufgerufen, um Diffs zu generieren, und Git verwendet nicht seine integrierte Diff-Funktion. Für einen Pfad, der hinzugefügt, entfernt oder geändert wurde, 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, die `GIT_EXTERNAL_DIFF` verwenden kann, um den Inhalt von <old|new> zu lesen,

<old|new>-hex
die 40-stelligen SHA-1-Hashes,

<old|new>-mode
die oktale Darstellung der Dateimodus.

Die Dateiparameter können auf die Arbeitsdatei des Benutzers (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) verweisen. GIT_EXTERNAL_DIFF muss sich keine Sorgen machen, die temporäre Datei zu löschen – sie wird entfernt, wenn GIT_EXTERNAL_DIFF beendet wird.

Für einen Pfad, der nicht zusammengeführt wurde, wird GIT_EXTERNAL_DIFF mit 1 Parameter, , aufgerufen.

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

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, wie in 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 Gesamtanzahl 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 auf 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 verzögert werden sollen, bevor optionale Fortschrittsanzeigen angezeigt werden. Standardmäßig 2.

GIT_EDITOR
Diese Umgebungsvariable überschreibt $EDITOR und $VISUAL. Sie wird von mehreren Git-Befehlen verwendet, wenn in einem 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, wenn die Aufgabenliste eines interaktiven Rebase bearbeitet wird. 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 eine Verbindung zu einem Remote-System herstellen müssen. Die Befehlszeilenparameter, die an den konfigurierten Befehl übergeben werden, 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 das Hinzufügen zusätzlicher Argumente ermöglicht. $GIT_SSH hingegen muss nur der Pfad zu einem Programm sein (das ein Wrapper-Shell-Skript sein kann, wenn zusätzliche Argumente benötigt werden).

Normalerweise ist es einfacher, alle gewünschten Optionen in Ihrer persönlichen .ssh/config-Datei zu konfigurieren. Bitte konsultieren Sie die ssh-Dokumentation für weitere Details.

GIT_SSH_VARIANT
Wenn diese Umgebungsvariable gesetzt ist, überschreibt sie die automatische Erkennung durch 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
Wenn diese Umgebungsvariable auf einen beliebigen Wert gesetzt und exportiert wird, wird Git angewiesen, das SSL-Zertifikat beim Abrufen oder Pushen über HTTPS nicht zu überprüfen.

GIT_ATTR_SOURCE
Legt das Treeish fest, aus dem gitattributes gelesen wird.

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

GIT_TERMINAL_PROMPT
Wenn diese boolesche Umgebungsvariable auf false gesetzt ist, fordert Git nicht auf dem Terminal auf (z. B. wenn es um die HTTP-Authentifizierung bittet).

GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM
Verwenden Sie die Konfiguration aus den angegebenen Dateien anstelle der globalen oder systemweiten Konfigurationsdateien. Wenn GIT_CONFIG_SYSTEM gesetzt ist, wird die Systemkonfigurationsdatei, die zur Build-Zeit definiert wurde (normalerweise /etc/gitconfig), nicht gelesen. Ebenso wird, 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 der Konfigurationsdateien auf der jeweiligen Ebene zu überspringen.

GIT_CONFIG_NOSYSTEM

Ob es die Einstellungen aus der systemweiten Datei $(prefix)/etc/gitconfig überspringen soll. Diese Boolesche Umgebungsvariable kann zusammen mit $HOME und $XDG_CONFIG_HOME verwendet werden, um eine vorhersagbare Umgebung für ein anspruchsvolles Skript zu erstellen, oder Sie können sie auf „true“ setzen, um vorübergehend die Verwendung einer fehlerhaften Datei /etc/gitconfig zu vermeiden, während Sie darauf warten, dass jemand mit ausreichenden Berechtigungen diese behebt.

GIT_FLUSH

Wenn diese Boolesche Umgebungsvariable auf „true“ gesetzt ist, zwingen Befehle wie git blame (im inkrementellen Modus), git rev-list, git log, git check-attr und git check-ignore, den Ausgabestrom nach jeder ausgegebenen Zeile zu leeren. Wenn diese Variable auf „false“ gesetzt ist, erfolgt die Ausgabe dieser Befehle mit vollständig gepuffertem I/O. Wenn diese Umgebungsvariable nicht gesetzt ist, wählt Git zwischen gepuffertem oder zeilenweise leeren, je nachdem, ob stdout in eine Datei umgeleitet wird oder nicht.

GIT_TRACE

Aktiviert allgemeine Tracemeldungen, z. B. Alias-Erweiterung, Ausführung von integrierten Befehlen und Ausführung externer Befehle.

Wenn diese Variable auf „1“, „2“ oder „true“ (Groß-/Kleinschreibung wird nicht beachtet) gesetzt ist, werden die Tracemeldungen nach stderr ausgegeben.

Wenn die Variable auf einen ganzzahligen Wert größer als 2 und kleiner als 10 (einschließlich) gesetzt ist, interpretiert Git diesen Wert als einen offenen Dateideskriptor und versucht, die Tracemeldungen in diesen Dateideskriptor zu schreiben.

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

Das Aufheben der Einstellung der Variablen oder das Setzen auf leer, „0“ oder „false“ (Groß-/Kleinschreibung wird nicht beachtet) deaktiviert die Tracemeldungen.

GIT_TRACE_FSMONITOR

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

GIT_TRACE_PACK_ACCESS

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

GIT_TRACE_PACKET

Aktiviert Tracemeldungen für alle Pakete, die in ein Programm ein- oder aus diesem herausgehen. Dies kann bei der Fehlersuche bei Objektverhandlungen oder anderen Protokollproblemen helfen. Das Tracing wird bei einem Paket, das mit „PACK“ beginnt (siehe GIT_TRACE_PACKFILE unten), deaktiviert. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_PACKFILE

Aktiviert das Tracing von Packdateien, die von einem Programm gesendet oder empfangen werden. Im Gegensatz zu anderen Trace-Ausgaben ist diese Trace-Ausgabe wörtlich: keine Header und keine Kodierung von Binärdaten. Sie möchten diese höchstwahrscheinlich in eine Datei umleiten (z. B. GIT_TRACE_PACKFILE=/tmp/my.pack), anstatt sie auf dem Terminal anzuzeigen oder mit anderen Trace-Ausgaben zu mischen.

GIT_TRACE_PERFORMANCE

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

GIT_TRACE_REFS

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

GIT_TRACE_SETUP

Aktiviert Trace-Meldungen, die das .git-, das Arbeitsverzeichnis und das aktuelle Arbeitsverzeichnis ausgeben, nachdem Git seine Initialisierungsphase abgeschlossen hat. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_SHALLOW

Aktiviert Trace-Meldungen, die bei der Fehlersuche beim Abrufen/Klonen von flachen Repositories helfen können. Siehe GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_CURL

Aktiviert einen vollständigen Curl-Trace aller eingehenden und ausgehenden Daten, einschließlich beschreibender Informationen, des Git-Transportprotokolls. Dies ähnelt der Verwendung von curl --trace-ascii in der Befehlszeile. 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. es werden nur Info-Zeilen und Header ausgegeben).

GIT_TRACE2

Aktiviert detailliertere Trace-Meldungen 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 zwischen Groß- und Kleinschreibung), werden Trace-Meldungen an stderr ausgegeben.

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

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

Darüber hinaus versucht Git, wenn die Variable auf af_unix:[:] gesetzt ist, den Pfad als Unix Domain Socket zu öffnen. Der Socket-Typ kann entweder Stream oder Dgram sein.

Das Aufheben der Einstellung der Variable oder das Setzen auf leer, "0" oder "false" (Groß-/Kleinschreibung wird nicht berücksichtigt) deaktiviert die Trace-Meldungen.

Siehe die Trace2-Dokumentation[2] für vollständige Details.

GIT_TRACE2_EVENT

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

GIT_TRACE2_PERF

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

GIT_TRACE_REDACT

Standardmäßig redigiert Git bei aktiviertem Tracing die Werte von Cookies, dem Header „Authorization:“, dem Header „Proxy-Authorization:“ und die URIs von Packdateien. Setzen Sie diese boolesche Umgebungsvariable auf „false“, um diese Redaktion zu verhindern.

GIT_NO_REPLACE_OBJECTS

Durch das Setzen und Exportieren dieser Umgebungsvariablen wird Git angewiesen, Ersatz-Refs zu ignorieren und keine Git-Objekte zu ersetzen.

GIT_LITERAL_PATHSPECS

Durch das Setzen dieser booleschen Umgebungsvariablen auf „true“ wird Git dazu veranlasst, alle Pfadspezifikationen wörtlich zu behandeln, anstatt als Glob-Muster. Wenn Sie beispielsweise GIT_LITERAL_PATHSPECS=1 git log -- '\*.c' ausführen, wird nach Commits gesucht, die den Pfad *.c betreffen, und nicht nach allen Pfaden, die das Glob-Muster *.c erfüllt. Dies kann nützlich sein, wenn Sie Git wörtliche Pfade übergeben (z. B. Pfade, die zuvor von git ls-tree, der --raw-Diff-Ausgabe usw. bereitgestellt wurden).

GIT_GLOB_PATHSPECS

Durch das Setzen dieser booleschen Umgebungsvariablen auf „true“ wird Git dazu veranlasst, alle Pfadspezifikationen als Glob-Muster (auch „Glob“-Magie genannt) zu behandeln.

GIT_NOGLOB_PATHSPECS

Durch das Setzen dieser booleschen Umgebungsvariablen auf „true“ wird Git dazu veranlasst, alle Pfadspezifikationen als Literal (auch „Literal“-Magie genannt) zu behandeln.

GIT_ICASE_PATHSPECS

Durch das Setzen dieser booleschen Umgebungsvariablen auf „true“ wird Git dazu veranlasst, alle Pfadspezifikationen als Groß-/Kleinschreibung-unempfindlich zu behandeln.

GIT_NO_LAZY_FETCH

Durch das Setzen dieser booleschen Umgebungsvariablen auf „true“ wird Git angewiesen, fehlende Objekte nicht bei Bedarf vom Promise-Remote-Repository nachzuladen.

GIT_REFLOG_ACTION

Wenn ein Ref aktualisiert wird, werden Reflog-Einträge erstellt, um den Grund für die Aktualisierung des Ref zu verfolgen (dies ist normalerweise der Name des High-Level-Befehls, der den Ref aktualisiert hat), zusätzlich zu den alten und neuen Werten des Ref. Ein in Scriptsprachen geschriebenes Porcelain-Kommando kann die Hilfsfunktion set_reflog_action in git-sh-setup verwenden, um ihren Namen auf diese Variable zu setzen, wenn sie als oberster Befehl vom Endbenutzer aufgerufen wird, um im Reflog-Text gespeichert zu werden.

GIT_REF_PARANOIA

Wenn diese boolesche Umgebungsvariable auf „false“ gesetzt ist, werden beim Durchlaufen von Listen von Refs defekte oder schlecht benannte Refs ignoriert. Normalerweise versucht Git, alle solchen 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 abgebrochen werden sollten, als defekte Refs zu ignorieren (und somit die Geschichte, auf die sie verweisen, nicht als schützenswert zu betrachten). Der Standardwert ist 1 (d. h. paranoid bei der Erkennung und dem Abbruch aller Operationen). Normalerweise müssen Sie dies nicht auf 0 setzen, aber es kann nützlich sein, wenn Sie versuchen, Daten aus einem beschädigten Repository wiederherzustellen.

GIT_COMMIT_GRAPH_PARANOIA

Beim Laden eines Commit-Objekts aus dem Commit-Graph führt Git eine Existenzprüfung des Objekts in der Objekt-Datenbank durch. Dies geschieht, um Probleme mit veralteten Commit-Graphen zu vermeiden, die Referenzen auf bereits gelöschte Commits enthalten, hat aber einen Einfluss auf die Leistung.

Der Standardwert ist „false“, wodurch das oben genannte Verhalten deaktiviert wird. Durch das Setzen auf „true“ wird die Existenzprüfung aktiviert, sodass niemals veraltete Commits aus dem Commit-Graph zurückgegeben werden, dies geht jedoch zu Lasten der Leistung.

GIT_ALLOW_PROTOCOL

Wenn auf eine durch Doppelpunkte getrennte Liste von Protokollen gesetzt, verhält es sich, als ob protocol.allow auf never gesetzt wäre und jedes der aufgeführten Protokolle protocol.<name>.allow auf always gesetzt hätte (wobei alle vorhandenen Konfigurationen überschrieben werden). 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 zu verhindern, dass Protokolle verwendet werden, die von fetch/push/clone verwendet werden und die für den Benutzerzustand konfiguriert sind. Dies ist nützlich, um rekursive Submodul-Initialisierungen aus einem nicht vertrauenswürdigen Repository einzuschränken oder für Programme, die potenziell nicht vertrauenswürdige URLs an Git-Befehle weitergeben. 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 so konfiguriert werden müssen, dass diese Variable über einige Transports übertragen werden kann. Sie wird automatisch weitergeleitet, wenn auf lokale Repositories zugegriffen wird (d. h. file:// oder ein Dateisystempfad) sowie über das git://-Protokoll. Für git-over-http sollte es in den meisten Konfigurationen automatisch funktionieren, aber siehe die Diskussion in git-httpbackend(1). Für git-over-ssh muss möglicherweise der SSH-Server so konfiguriert werden, dass Clients diese Variable übergeben können (z. B. durch Verwendung von AcceptEnv GIT_PROTOCOL mit OpenSSH).

Diese Konfiguration ist optional. Wenn die Variable nicht weitergeleitet wird, greifen Clients auf das ursprüngliche „v0“-Protokoll zurück (verpassen aber möglicherweise einige Leistungsverbesserungen oder Funktionen). Diese Variable wirkt sich derzeit nur auf Klonen und Abrufen aus; sie wird noch nicht für Push-Operationen verwendet (dies könnte jedoch in Zukunft der Fall sein).

GIT_OPTIONAL_LOCKS

Wenn diese boolesche Umgebungsvariable auf false gesetzt ist, führt Git alle angeforderten Operationen aus, ohne optionale Teiloperationen durchzuführen, die das Sperren erfordern. Zum Beispiel verhindert dies, dass git status den Index als Nebenwirkung aktualisiert. Dies ist nützlich für Prozesse, die im Hintergrund ausgeführt werden und keine Sperrkonflikte mit anderen Operationen im Repository verursachen möchten. Standardmäßig auf 1 gesetzt.

GIT_REDIRECT_STDIN, GIT_REDIRECT_STDOUT, GIT_REDIRECT_STDERR

Nur Windows: Ermöglicht das Umleiten der Standard-Eingabe-/Ausgabe-/Fehler-Handles in Pfade, die von den Umgebungsvariablen angegeben werden. Dies ist besonders nützlich in Multithread-Anwendungen, bei denen die kanonische Methode zum Übergeben von Standard-Handles über CreateProcess() keine Option ist, da dies dazu führen würde, dass die Handles für alle gestarteten Prozesse markiert werden müssen, was reguläre Git-Operationen blockieren würde. Der Hauptanwendungsfall ist die Verwendung von benannten Pipes für die Kommunikation (z. B. \\.\pipe\my-git-stdin-123).

Zwei spezielle Werte werden unterstützt: off schließt einfach das entsprechende Standard-Handle, und wenn GIT_REDIRECT_STDERR auf 2>&1 gesetzt ist, wird die Standardausgabe in dasselbe Handle wie die Standardausgabe umgeleitet.

GIT_PRINT_SHA1_ELLIPSIS (veraltet)

Wenn auf „yes“ gesetzt, wird nach einem (gekürzten) SHA-1-Wert eine Auslassung (Ellipsis) gedruckt. Dies betrifft die Anzeige von „detached HEADs“ (git-checkout(1)) und die rohe Diff-Ausgabe (git-diff(1)). Das Drucken einer Auslassung in den genannten Fällen wird nicht mehr als angemessen angesehen, und die Unterstützung dafür wird in naher Zukunft wahrscheinlich entfernt (zusammen mit der Variablen).

GIT_ADVICE

Wenn auf 0 gesetzt, werden alle Hinweismeldungen deaktiviert. Diese Meldungen sollen menschlichen Benutzern Hinweise geben, die ihnen helfen können, problematische Situationen zu lösen oder neue Funktionen zu nutzen. Benutzer können einzelne Meldungen mithilfe der Konfigurationsschlüssel „advice.*“ deaktivieren. Diese Meldungen können für Tools, die Git-Prozesse ausführen, störend sein, daher ist diese Variable zum Deaktivieren der Meldungen verfügbar. (Die globale Option „--no-advice“ ist ebenfalls verfügbar, ältere Git-Versionen können jedoch fehlschlagen, wenn diese Option nicht verstanden wird. Die Umgebungsvariable wird von Git-Versionen, die sie nicht verstehen, ignoriert).

DISKUSSION

Weitere Details finden Sie im Git-Konzeptkapitel des Benutzerhandbuchs[3] und in gitcore-tutorial(7).

Ein Git-Projekt besteht normalerweise aus einem Arbeitsverzeichnis mit einem „.git“-Unterverzeichnis auf der obersten 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 verbindet, und benannte Zeiger in dieser Historie,
wie z. B. Tags und Branch-Heads.

Die Objektdatenbank enthält Objekte von drei Haupttypen: Blobs, die Datei-Daten enthalten; Trees, die auf Blobs und andere Trees verweisen, um Verzeichnisstrukturen aufzubauen; und Commits, die jeweils auf einen einzigen Tree und eine Anzahl von übergeordneten Commits verweisen.

Das Commit, das dem entspricht, was andere Systeme als „Änderungssatz“ oder „Version“ bezeichnen, stellt einen Schritt in der Projektgeschichte dar, und jeder übergeordnete Eintrag stellt einen unmittelbar vorhergehenden Schritt dar. Commits mit mehr als einem übergeordneten Eintrag stellen das Zusammenführen unabhängiger Entwicklungszweige dar.

Alle Objekte sind nach dem SHA-1-Hash ihres Inhalts benannt, normalerweise als eine Zeichenfolge aus 40 hexadezimalen Ziffern geschrieben. Solche Namen sind global eindeutig. Die gesamte Historie bis zu einem Commit kann durch die Signierung dieses Commits bestätigt werden. Ein vierter Objekttyp, das Tag, ist dafür vorgesehen.

Wenn sie zum ersten Mal erstellt werden, werden Objekte in einzelnen Dateien gespeichert, können aber zur Effizienzsteigerung später in „Pack-Dateien“ komprimiert werden.

Benannte Zeiger, die als „Refs“ bezeichnet werden, markieren interessante Punkte in der Historie. Ein Ref kann den SHA-1-Namen eines Objekts oder den Namen eines anderen Ref 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 in der Entwicklung befindlichen Branch. Die SHA-1-Namen von interessanten Tags werden unter „refs/tags/“ gespeichert. Ein symbolischer Ref namens „HEAD“ enthält den Namen des derzeit ausgecheckten Branch.

Die Indexdatei wird mit einer Liste aller Pfade initialisiert, und für jeden Pfad wird ein Blob-Objekt und eine Menge von Attributen gespeichert. Das Blob-Objekt repräsentiert den Inhalt der Datei, so wie er am Ende des aktuellen Zweigs vorliegt. Die Attribute (letzte Änderungszeit, Größe usw.) werden aus der entsprechenden Datei im Arbeitsverzeichnis übernommen. Nachfolgende Änderungen im Arbeitsverzeichnis können durch einen Vergleich dieser Attribute ermittelt werden. Der Index kann mit neuen Inhalten aktualisiert werden, und aus den im Index gespeicherten Inhalten können neue Commits erstellt werden.

Der Index kann auch mehrere Einträge (sogenannte „Stufen“) für einen bestimmten Pfadnamen speichern. Diese Stufen werden verwendet, um die verschiedenen nicht zusammengeführten Versionen einer Datei zu speichern, wenn ein Merge-Vorgang stattfindet.

SICHERHEIT

Einige Konfigurationsoptionen und Hook-Dateien können dazu führen, dass Git beliebige Shell-Befehle ausführt. Da Konfigurationen und Hooks nicht mit git clone kopiert werden, ist es im Allgemeinen sicher, Remote-Repositories mit nicht vertrauenswürdigen Inhalten zu klonen und diese mit git log zu untersuchen usw.

Es ist jedoch nicht sicher, Git-Befehle in einem .git-Verzeichnis (oder dem Arbeitsverzeichnis, das dieses umgibt) auszuführen, wenn dieses .git-Verzeichnis selbst aus einer nicht vertrauenswürdigen Quelle stammt. Die in der Konfiguration und den Hooks enthaltenen Befehle werden auf die übliche Weise ausgeführt.

Standardmäßig wird Git sich weigern, ausgeführt zu werden, wenn das Repository nicht dem Benutzer gehört, der den Befehl ausführt. Siehe den Eintrag für safe.directory in git-config(1). Obwohl dies dazu beitragen kann, Sie in einer Multi-User-Umgebung zu schützen, sollten Sie beachten, dass Sie auch nicht vertrauenswürdige Repositories erhalten können, die Ihnen gehören (z. B. wenn Sie eine ZIP- oder Tar-Datei aus einer nicht vertrauenswürdigen Quelle extrahieren). In solchen Fällen müssen Sie das nicht vertrauenswürdige Repository zuerst „bereinigen“.

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 die Menge der Optionen und Hooks ein, die von upload-pack ausgeführt werden, das die Serverseite eines Klon- oder Fetch-Vorgangs übernimmt, aber beachten Sie, dass die Angriffsfläche für upload-pack groß ist, so dass dies ein gewisses Risiko birgt. Das Sicherste ist, das Repository als nicht privilegierter Benutzer bereitzustellen (entweder über git-daemon(1), SSH oder durch die Verwendung anderer Tools, um die Benutzer-IDs zu ändern). Siehe die Diskussion im Abschnitt „SICHERHEIT“ von git-upload-pack(1).

WEITERE DOKUMENTATION

Siehe die Referenzen im Abschnitt „Beschreibung“, um mit der Verwendung von Git zu beginnen. Das Folgende enthält wahrscheinlich mehr Details, als ein Erstbenutzer benötigt.

Das Kapitel „Git-Konzepte“ des Benutzerhandbuchs [3] und gitcore-tutorial(7) bieten beide eine Einführung in die zugrunde liegende Git-Architektur.

Siehe gitworkflows(7) für einen Überblick über empfohlene Workflows.

Siehe auch die Howto-Dokumente [4] für einige nützliche Beispiele.

Die internen Abläufe sind in der Git-API-Dokumentation [5] 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 gewartet. Zahlreiche Beiträge stammen von der Git-Mailingliste <_[6]>. ^ ttps://openhub.net/p/git/contributors/summary gibt Ihnen eine vollständigere Liste der Mitwirkenden.

Wenn Sie eine Kopie 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.

FEHLER MELDEN

Melden Sie Fehler an die Git-Mailingliste <_[6]>, wo die Entwicklung und Wartung hauptsächlich stattfindet. Sie müssen nicht Mitglied der Liste sein, um eine Nachricht dorthin zu senden. Sehen Sie sich das Archiv der Liste unter https://lore.kernel.org/git an, um frühere Fehlerberichte und andere Diskussionen einzusehen.

Sicherheitsrelevante Probleme sollten privat an die Git-Sicherheits-Mailingliste <_[7]> gemeldet werden.

SIEHE AUCH

gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcoretutorial(7), gitcli(7), Das Git-Benutzerhandbuch[1], gitworkflows(7)

GIT

Teil der git(1)-Suite

HINWEISE

    Git-Benutzerhandbuch
file:///usr/share/doc/git/html/user-manual.html

    Trace2-Dokumentation
file:///usr/share/doc/git/html/technical/api-trace2.html

    Git-Konzeptkapitel des Benutzerhandbuchs
file:///usr/share/doc/git/html/user-manual.html#git-concepts

howto
file:///usr/share/doc/git/html/howto-index.html

    Git-API-Dokumentation
file:///usr/share/doc/git/html/technical/api-index.html

_
mailto:_

_
mailto:_