Git

git last updated in 2.43.0

NAME

git - der stupide Content-Tracker

ÜBERSICHT

git [--version] [--help] [-C <Pfad>] [-c <Name>=<Wert>]
    [--exec-path[=<Pfad>]] [--html-path] [--man-path] [--info-path]
    [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
    [--git-dir=<Pfad>] [--work-tree=<Pfad>] [--namespace=<Name>]
    [--super-prefix=<Pfad>]
    <Befehl> [<Argumente>]

BESCHREIBUNG

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

Siehe gittutorial[7] für den Einstieg und anschließend giteveryday[7] für einen nützlichen Mindestbefehlssatz. Das Git-Nutzerhandbuch enthält eine tiefergehende Einführung.

Wenn Sie die grundlegenden Konzepte verstanden haben, können Sie auf dieser Seite lernen, welche Befehle Git anbietet. Mit "git help <Befehl>" können Sie mehr über einzelne Git-Befehle erfahren. Die Handbuchseite gitcli[7] bietet Ihnen einen Überblick über die Befehlszeilen-Syntax.

Eine HTML-Version der aktuellen Git-Dokumentation mit Formatierung und Verknüpfungen ist unter https://git.github.io/htmldocs/git.html oder https://git-scm.com/docs verfügbar.

OPTIONEN

--version

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

--help

Gibt eine Übersicht und eine Liste der gebräuchlichsten Befehle aus. Wenn die Option --all oder -a angegeben wurde, werden alle verfügbaren Befehle ausgegeben. Falls der Name eines Git-Befehls angegeben wurde, wird die Handbuchseite für diesen Befehl geöffnet.

Zur Steuerung wie die Handbuchseite dargestellt wird sind andere Optionen verfügbar. Weitere Informationen finden Sie unter git-help[1], weil git --help ... intern in git help ... konvertiert wird.

-C <Pfad>

Git ausführen, als ob Git in <Pfad> statt dem aktuellen Arbeitsverzeichnis gestartet wurde. Falls die Option -C mehrfach angegeben wurde, wird jeder nicht-absolute -C <Pfad> als relativ zum vorherigen -C <Pfad> interpretiert. Wenn <Pfad> existiert, aber leer ist (also -C ""), wird das aktuelle Arbeitsverzeichnis nicht verändert.

Diese Option beeinflusst andere Optionen, die Pfade erwarten, wie --git-dir`und `--work-tree, da ihre Pfade relativ zum Arbeitsverzeichnis, das über -C angegeben wurde, interpretiert werden. Die folgenden Aufrufe sind z.B. identisch:

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 übergebene Wert Überschreibt Werte aus Konfigurationsdateien. Der <Name> wird im gleichen Format erwartet, das von git config ausgegeben wird. (Unterschlüssel durch Punkte getrennt).

Beachten Sie, dass das Weglassen des = in git -c foo.bar ... erlaubt ist und foo.bar auf true setzt (genau wie [foo]bar in einer Konfigurationsdatei). Ein Gleichheitszeichen ohne Wert (wie git -c foo.bar= ...) setzt foo.bar auf einen leeren String, den git config --type=bool in false konvertiert.

--exec-path[=<Pfad>]

Installationspfad Ihrer Git-Programme. Dies kann auch durch Setzen der Umgebungsvariable GIT_EXEC_PATH. Wenn kein Pfad angegeben ist, gibt git die aktuelle Einstellung aus.

--html-path

Ausgabe des Pfads in dem Git’s HTML-Dokumentation installiert ist ohne abschließenden Schrägstrich.

--man-path

Ausgabe des Handbuchpfads (siehe man(1)) für die Handbuchseiten für diese Git-Version.

--info-path

Ausgave des Pfads in dem die Info-Dateien die diese Git-Version dokumentieren installiert sind.

-p

--paginate

Alle Ausgaben an less (oder, falls gesetzt $PAGER) weiterleiten, falls die Standard-Ausgabe ein terminal ist. Dies setzt sich über die pager.<cmd> Konfigurationsoptionen hinweg (siehe Abschnitt "Configuration Mechanism" weiter unten).

-P

--no-pager

Git-Ausgaben nicht an einen Pager weiterleiten.

--git-dir=<Pfad>

Set the path to the repository (".git" directory). This can also be controlled by setting the GIT_DIR environment variable. It can be an absolute path or relative path to current working directory.

Specifying the location of the ".git" directory using this option (or GIT_DIR environment variable) turns off the repository discovery that tries to find a directory with ".git" subdirectory (which is how the repository and the top-level of the working tree are discovered), and tells Git that you are at the top level of the working tree. If you are not at the top-level directory of the working tree, you should tell Git where the top-level of the working tree is, with the --work-tree=<path> option (or GIT_WORK_TREE environment variable)

If you just want to run git as if it was started in <path> then use git -C <path>.

--work-tree=<Pfad>

Set the path to the working tree. It can be an absolute path or a path relative to the current working directory. This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable (see core.worktree in git-config[1] for a more detailed discussion).

--namespace=<Pfad>

Setzt den Git Namespace. Siehe gitnamespaces[7] für weitere Details. Dies entspricht dem Setzen der Umgebungsvariable GIT_NAMESPACE.

--super-prefix=<Pfad>

Currently for internal use only. Set a prefix which gives a path from above a repository down to its root. One use is to give submodules context about the superproject that invoked it.

--bare

Das Repository als Bare-Repository behandeln. Wenn die Umgebungsvariable GIT_DIR nicht gestezt ist, wird sie auf das aktuelle Arbeitsverzeichnis gesetzt.

--no-replace-objects

Do not use replacement refs to replace Git objects. See git-replace[1] for more information.

--literal-pathspecs

Pfadspezifikationen buchstäblich (d.h. kein Globbing, keine Pfadspezifikationsangaben) behandeln. Dies entspricht dem Setzen der Umgebungsvariable GIT_LITERAL_PATHSPECS auf 1.

--glob-pathspecs

Fügt die Pfadspezifikationsangabe "glob" zu allen Pfadspezifikationen hinzu. Dies entspricht dem Setzen der Umgebungsvariable GIT_GLOB_PATHSPECS auf 1. Globbing kann für einzelne Pfadspezifikationen mit der Pfadspezifikationsangabe ":(literal)" deaktiviert werden

--noglob-pathspecs

Fügt die Pfadspezifikationsangabe "literal" zu allen Pfadspezifikationen hinzu. Dies entspricht dem Setzen der Umgebungsvariable GIT_NOGLOB_PATHSPECS auf 1. Globbing kann für einzelne Pfadspezifikationen mit der Pfadspezifikationsangabe ":(glob)" aktiviert werden

--icase-pathspecs

Fügt die Pfadspezifikationsangabe "icase" zu allen Pfadspezifikationen hinzu. Dies entspricht dem Setzen der Umgebungsvariable GIT_ICASE_PATHSPECS auf 1.

--no-optional-locks

Führt keine optionalen Operationen durch, die Sperren erfordern. Dies entspricht dem Setzen von GIT_OPTIONAL_LOCKS auf 0.

--list-cmds=Gruppe[,Gruppe…]

Befehle nach Gruppe auflisten. Dies ist eine interne/experimentelle Option und könnte in zukunft geändert oder entfernt werden. Unterstützt folgende Gruppen: builtins (Integrierte Befehle), parseopt (Integrierte Befehle, die Parse-Optionen verwenden), main (Alle Befehle im Verzeichnis libexec), others (Alle anderen Befehle in $PATH mit Präfix git-), list-<Kategorie> (siehe Kategorien in command-list.txt), nohelpers (Hilfsbefehle ausschließen), alias and config (Befehlsliste aus Konfigurationsvariable completion.commands)

GIT-BEFEHLE

Wir unterteilen Git in hochrangige Befehle ("Porcelain") und Systembefehle ("Plumbing").

Hochrangige Befehle (Porcelain)

Wir unterteilen "Porcelain"-Befehle in Hauptbefehle und zusätzliche Benutzerwerkzeuge.

Hauptbefehle

git-add[1]: Füge Dateiinhalte zum Index hinzu.
git-am[1]: Eine Serie von Patches von einer Mailbox anwenden.
git-archive[1]: Dateiarchiv von angegebenem Verzeichnis erstellen.
git-bisect[1]: Binärsuche verwenden, um den Commit zu finden, der einen Fehler verursacht hat.
git-branch[1]: Branches anzeigen, erstellen oder entfernen.
git-bundle[1]: Objekte und Referenzen über ein Archiv verteilen.
git-checkout[1]: Branches wechseln oder Dateien im Arbeitsverzeichnis wiederherstellen.
git-cherry-pick[1]: Änderungen eines existierenden Commits anwenden.
git-citool[1]: Graphische Alternative zu git-commit.
git-clean[1]: Unversionierte Dateien vom Arbeitsverzeichnis entfernen.
git-clone[1]: Ein Repository in einem neuen Verzeichnis klonen.
git-commit[1]: Änderungen in das Repository eintragen.
git-describe[1]: Einem Objekt einen für Menschen lesbaren Namen basierend auf einer verfügbaren Referenz geben.
git-diff[1]: Änderungen zwischen Commits, Commit und Arbeitsverzeichnis, etc. anzeigen.
git-fetch[1]: Objekte und Referenzen von einem anderen Repository herunterladen.
git-format-patch[1]: Patches für E-Mail-Versand vorbereiten.
git-gc[1]: Nicht benötigte Dateien entfernen und das lokale Repository optimieren.
git-grep[1]: Zeilen darstellen, die einem Muster entsprechen.
git-gui[1]: Eine portable grafische Schnittstelle zu Git.
git-init[1]: Ein leeres Git-Repository erstellen oder ein bestehendes neuinitialisieren.
git-log[1]: Commit-Historie anzeigen.
git-merge[1]: Zwei oder mehr Entwicklungszweige zusammenführen.
git-mv[1]: Eine Datei, ein Verzeichnis oder einen Symlink verschieben oder umbenennen.
git-notes[1]: Objekt-Notizen hinzufügen oder überprüfen.
git-pull[1]: Objekte von einem externen Repository anfordern und sie mit einem anderen Repository oder einem lokalen Branch zusammenführen.
git-push[1]: Remote-Referenzen mitsamt den verbundenen Objekten aktualisieren.
git-range-diff[1]: Vergleiche zwei Commit-Bereiche (z.B. zwei Versionen eines Branches).
git-rebase[1]: Wiederholtes Anwenden von Commits auf anderem Basis-Commit.
git-reset[1]: Aktuellen HEAD zu einem spezifizierten Zustand setzen.
git-restore[1]: Dateien im Arbeitsverzeichnis wiederherstellen.
git-revert[1]: Einige bestehende Commits rückgängig machen.
git-rm[1]: Dateien aus dem Arbeitsverzeichnis und dem Index löschen.
git-shortlog[1]: Ausgabe von git log zusammenfassen.
git-show[1]: Verschiedene Arten von Objekten anzeigen.
git-sparse-checkout[1]: Initialize and modify the sparse-checkout.
git-stash[1]: Änderungen in einem Arbeitsverzeichnis aufbewahren.
git-status[1]: Den Zustand des Arbeitsverzeichnisses anzeigen.
git-submodule[1]: Submodule initialisieren, aktualisieren oder inspizieren.
git-switch[1]: Branches wechseln.
git-tag[1]: Ein mit GPG signiertes Tag-Objekt erzeugen, auflisten, löschen oder verifizieren.
git-worktree[1]: Mehrere Arbeitsverzeichnisse verwalten.
gitk[1]: Der Git-Repository-Browser.

Nebenbefehle

Manipulatoren:

git-config[1]: Repositoryweite oder globale Optionen lesen und setzen.
git-fast-export[1]: Export-Tool für Git-Daten.
git-fast-import[1]: Backend für schnelle Git-Datenimport-Tools.
git-filter-branch[1]: Branches umschreiben.
git-mergetool[1]: Ausführen von Tools zur Auflösung von Merge-Konflikten zur Behebung dieser.
git-pack-refs[1]: Branches und Tags für effizienten Zugriff auf das Repository packen.
git-prune[1]: Alle nicht erreichbaren Objekte von der Objektdatenbank entfernen.
git-reflog[1]: Reflog-Informationen verwalten.
git-remote[1]: Einen Satz entfernter Repositories verwalten.
git-repack[1]: Ungepackte Objekte in einem Repository packen.
git-replace[1]: Referenzen für ersetzende Objekte erstellen, auflisten, löschen.

Abfragen:

git-annotate[1]: Zeilen der Datei mit Commit-Informationen versehen und anzeigen.
git-blame[1]: Anzeigen, durch welchen Commit und Autor die jeweiligen Zeilen einer Datei zuletzt geändert wurden.
git-bugreport[1]: Collect information for user to file a bug report.
git-count-objects[1]: Anzahl und Speicherverbrauch ungepackter Objekte zählen.
git-difftool[1]: Änderungen mittels den allgemeinen Diff-Tools anzeigen.
git-fsck[1]: Stellt die Verbundenheit und Gültigkeit der Objekte in der Datenbank sicher.
git-help[1]: Hilfsinformationen über Git anzeigen.
git-instaweb[1]: Ihr aktuelles Repository sofort in gitweb betrachten.
git-merge-tree[1]: 3-Wege-Merge anzeigen ohne den Index zu verändern.
git-rerere[1]: Aufgezeichnete Auflösung von Merge-Konflikten wiederverwenden.
git-show-branch[1]: Branches und ihre Commits ausgeben.
git-verify-commit[1]: Die GPG-Signatur von Commits prüfen.
git-verify-tag[1]: Die GPG-Signatur von Tags prüfen.
git-whatchanged[1]: Logs mit dem Unterschied, den jeder Commit einführt, anzeigen.
gitweb[1]: Git Web Interface (Web-Frontend für Git-Repositories).

Mit anderen interagieren

Diese Befehle dienen zum Interagieren mit fremden Versionsverwalungen oder mit anderen Personen über Patch per E-Mail.

git-archimport[1]: Ein GNU-Arch-Repository in Git importieren.
git-cvsexportcommit[1]: Einzelnen Commit zu einem ausgecheckten CVS-Repository exportieren.
git-cvsimport[1]: Ihre Daten aus einem anderen SCM übernehmen.
git-cvsserver[1]: Ein CVS-Server-Emulator für Git.
git-imap-send[1]: Eine Sammlung von Patches von der Standard-Eingabe an einen IMAP-Ordner senden.
git-p4[1]: Repositories aus Perforce importieren und an diese senden.
git-quiltimport[1]: Patches aus quilt auf aktuellen Branch anwenden.
git-request-pull[1]: Eine Übersicht über ausstehende Änderungen generieren.
git-send-email[1]: Eine Sammlung von Patches als E-Mails versenden.
git-svn[1]: Bidirektionale Operationen zwischen einem Subversion-Repository und Git.

Reset, restore und revert

There are three commands with similar names: git reset, git restore and git revert.

git-revert[1] is about making a new commit that reverts the changes made by other commits.
git-restore[1] is about restoring files in the working tree from either the index or another commit. This command does not update your branch. The command can also be used to restore files in the index from another commit.
git-reset[1] is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history.

git reset can also be used to restore the index, overlapping with git restore.

Systembefehle ("Plumbing")

Auch wenn Git eigene hochrangige Befehle enthält, reichen die Systembefehle aus, um alternative hochrangige Befehle zu entwickeln. Entwickler solcher Befehle sollten sich zum Einstieg in git-update-index[1] und git-read-tree[1] einlesen.

Die Schnittstelle (Eingaben, Ausgaben, verfügbare Optionen und Semantik) zu diesen Systembefehlen sollen viel stabiler als "Porcelain"-Befehle sein, da sie hauptsächlich zum Gebrauch in Skripten vorgesehen sind. Bei der Schnittstelle zu "Porcelain"-Befehlen sind dagegen Änderungen zur Verbesserung der Benutzerfreundlichkeit vorbehalten.

Im folgenden Text werden die Systembefehle unterteilt in Befehle um Objekte (in the repository, index, and working tree) zu manipulieren, Befehle um Objekte abzufragen und zu vergleichen und Befehle um Objekte und Referenzen zwischen Repositories zu übertragen.

Manipulierende Befehle

git-apply[1]: Einen Patch auf Dateien und/oder den Index anwenden.
git-checkout-index[1]: Dateien von dem Index ins Arbeitsverzeichnis kopieren.
git-commit-graph[1]: Schreibe und verifiziere Git-Commit-Graph-Dateien.
git-commit-tree[1]: Ein neues Commit-Objekt erstellen.
git-hash-object[1]: Von einer Datei die Objekt-ID berechnen und optional ein Blob erstellen.
git-index-pack[1]: Pack-Index-Datei für ein existierendes gepacktes Archiv erzeugen.
git-merge-file[1]: Einen 3-Wege-Datei-Merge ausführen.
git-merge-index[1]: Einen Merge für zusammenzuführende Dateien ausführen.
git-mktag[1]: Ein Tag-Objekt erstellen.
git-mktree[1]: Tree-Objekt aus ls-tree formattiertem Text erzeugen.
git-multi-pack-index[1]: Schreibe und verifiziere Multipackindizes.
git-pack-objects[1]: Ein gepacktes Archiv von Objekten erstellen.
git-prune-packed[1]: Zusätzliche Objekte, die sich bereits in Paketdateien befinden, entfernen.
git-read-tree[1]: Verzeichnisinformationen in den Index einlesen.
git-symbolic-ref[1]: Symbolische Referenzen lesen, ändern und löschen.
git-unpack-objects[1]: Objekte aus einem gepackten Archiv entpacken.
git-update-index[1]: Dateiinhalte aus dem Arbeitsverzeichnis im Index registrieren.
git-update-ref[1]: Den Objektnamen, der in einer Referenz gespeichert ist, sicher aktualisieren.
git-write-tree[1]: Tree-Objekt vom aktuellen Index erstellen.

Abfragebefehle

git-cat-file[1]: Inhalt oder Informationen zu Typ und Größe für Repository-Objekte bereitstellen.
git-cherry[1]: Commits finden, die noch auf dem Upstream-Branch angewendet werden müssen.
git-diff-files[1]: Dateien von dem Arbeitsverzeichnis und dem Index vergleichen.
git-diff-index[1]: Ein Verzeichnis von dem Arbeitsverzeichnis und dem Index vergleichen.
git-diff-tree[1]: Den Inhalt und Modus von Blobs aus zwei Verzeichnisobjekten vergleichen.
git-for-each-ref[1]: Informationen für jede Referenz ausgeben.
git-get-tar-commit-id[1]: Commit-ID eines Archivs extrahieren, welches mit git-archive erstellt wurde.
git-ls-files[1]: Informationen über Dateien in dem Index und im Arbeitsverzeichnis anzeigen.
git-ls-remote[1]: Referenzen in einem Remote-Repository auflisten.
git-ls-tree[1]: Inhalte eines Tree-Objektes auflisten.
git-merge-base[1]: Bestmöglichen gemeinsamen Vorgänger-Commit für einen Merge finden.
git-name-rev[1]: Symbolische Namen für die gegebenen Commits finden.
git-pack-redundant[1]: Redundante Paketdateien finden.
git-rev-list[1]: Commit-Objekte chronologisch absteigend sortiert auflisten.
git-rev-parse[1]: Parameter herauspicken und ändern.
git-show-index[1]: Gepackten Archiv-Index anzeigen.
git-show-ref[1]: Referenzen in einem lokalen Repository auflisten.
git-unpack-file[1]: Eine temporäre Datei mit den Inhalten eines Blobs erstellen.
git-var[1]: Eine logische Variable von Git anzeigen.
git-verify-pack[1]: Gepackte Git-Archivdateien validieren.

Abfragebefehle verändern im Allgemeinen keine Dateien im Arbeitsverzeichnis.

Syncing repositories

git-daemon[1]: Ein wirklich 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 zu einem anderen Repository übertragen.
git-update-server-info[1]: Hilfsinformationsdatei zur Hilfe von einfachen Servern aktualisieren.

Die folgenden Befehle sind Hilfsbefehle für die oben genannten Befehle; Endbenutzer rufen sie normalerweise nicht direkt auf.

git-http-fetch[1]: Von einem Remote-Git-Repository über HTTP herunterladen.
git-http-push[1]: Objekte über HTTP/DAV zu einem anderen Repository übertragen.
git-parse-remote[1]: Routinen als Hilfe zum Parsen von Zugriffsparametern von Remote-Repositories.
git-receive-pack[1]: Empfangen was in das Repository übertragen wurde.
git-shell[1]: Login-Shell beschränkt für Nur-Git SSH-Zugriff.
git-upload-archive[1]: Archiv zurück zu git-archive senden.
git-upload-pack[1]: Objekte gepackt zurück an git-fetch-pack senden.

Interne Hilfsbefehle

Diese Befehle sind Hilfsbefehle für die andere Befehle; Endbenutzer rufen sie normalerweise nicht direkt auf.

git-check-attr[1]: gitattributes-Informationen darstellen.
git-check-ignore[1]: Fehlersuche in gitignore- / exclude-Dateien.
git-check-mailmap[1]: Name und E-Mail-Adresse von Kontakten anzeigen.
git-check-ref-format[1]: Sicherstellen, dass ein Referenzname wohlgeformt ist.
git-column[1]: Daten in Spalten anzeigen.
git-credential[1]: Zugangsdaten des Benutzers abrufen und speichern.
git-credential-cache[1]: Hilfsprogramm zum temporären Speichern von Zugangsdaten im Hauptspeicher.
git-credential-store[1]: Hilfsprogramm zum Speichern von Zugangsdaten auf der Festplatte.
git-fmt-merge-msg[1]: Beschreibung eines Merge-Commits erzeugen.
git-interpret-trailers[1]: Strukturierte Informationen in Commit-Beschreibungen hinzufügen oder parsen.
git-mailinfo[1]: Patch und Urheberschaft aus einer einzelnen E-Mail-Nachricht extrahieren.
git-mailsplit[1]: Einfaches UNIX mbox Splitter-Programm.
git-merge-one-file[1]: Das Standard-Hilfsprogramm für die Verwendung mit git-merge-index.
git-patch-id[1]: Eindeutige ID für einen Patch berechnen.
git-sh-i18n[1]: Git’s i18n-Konfigurationscode für Shell-Skripte.
git-sh-setup[1]: Allgemeiner Git Shell-Skript Konfigurationscode.
git-stripspace[1]: Nicht erforderlichen Whitespace entfernen.

Konfigurationsmechanismus

Git nutzt ein einfaches Textformat um Einstellungen pro Benutzer und Repository zu speichern. So eine Konfigurationsdatei kann wie folgt aussehen:

#
# Eine Raute '#' oder ein Semikolon ';' markiert # einen Kommentar.
#

; Kernvariablen
[core]
	; den Dateimodi nicht vertrauen
	filemode = false

; Identät des Nutzers
[user]
	name = "Junio C Hamano"
	email = "gitster@pobox.com"

Verschiedene Git-Befehle lesen die Konfigurationsdatei und passen ihr Verhalten entsprechend an. Siehe git-config[1] für eine Liste der Optionen und mehr Details über den Konfigurationsmechanismus.

Bezeichner-Terminologie

<Objekt>: Bezeichnet den Namen eines Objekts beliebigen Typs.
<Blob>: Bezeichnet den Namen eines Blob-Objekts.
<Tree>: Bezeichnet den Namen eines Tree-Objekts.
<Commit>: Bezeichnet den Namen eines Commit-Objekts.
<Commit-Referenz>: Bezeichnet den Namen eines Tree-, Commit- oder Markierungs-Objekts. Ein Befehl, der eine <Commit-Referenz> als Argument akzeptiert arbeitet letztendlich mit einem <Tree>-Objekt, dereferenziert aber auch automatisch <Commit>- und <Markierung>-Objekte, die auf einen <Tree> verweisen.
<Commit-Angabe>: Bezeichnet den Namen eines Commit- oder Markierungs-Objekts. Ein Befehl, der eine <Commit-Angabe> als Argument akzeptiert arbeitet letztendlich mit einem <Commit>-Objekt, dereferenziert aber auch automatisch <Markierung>-Objekte, die auf einen <Commit> verweisen.
<Art>: Gibt an, dass eine Objekt-Art benötigt wird. Momentan sind möglich: blob, tree, commit oder tag (Markierung).
<Datei>: Bezeichnet einen Dateinamen, der fast immer relativ zur Verzeichnisstruktur in GIT_INDEX_FILE ist.

Symbolische Bezeichner

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

HEAD: Bezeichnet die Spitze des aktuellen Entwicklungszweigs.
<Markierung>: Eine gültige Markierungsbezeichnung (d.h. ein refs/tags/<Markierung> Verweis).
<Branch>: Eine gültige Branch-Bezeichnung (d.h. ein refs/heads/<Branch> Verweis).

Für eine umfänglichere Auflistung wie Objektbezeichnungen angegeben werden können siehe den Abschnitt "REVISIONEN ANGEBEN" in gitrevisions[7].

Datei-/Verzeichnisstruktur

Siehe das Dokument gitrepository-layout[5].

Lesen Sie githooks[5] für mehr Details über die einzelnen Hooks.

Übergeordnete SCMs können zusätzliche Informationen im $GIT_DIR bereitstellen und verwalten.

Terminologie

Siehe gitglossary[7].

Umgebungsvariablen

Verschiedene Git-Befehle benutzen die folgenden Umgebungsvariablen:

Das Git-Repository

These environment variables apply to all core Git commands. Nb: it is worth noting that they may be used/overridden by SCMS sitting above Git so take care if using a foreign front-end.

GIT_INDEX_FILE: Diese Umgebungsvariable erlaubt es eine alternative Indexdatei anzugeben. Andernfalls wird die Standarddatei $GIT_DIR/index verwendet.
GIT_INDEX_VERSION: Mit dieser Umgebungsvariable kann die Indexversion für neue Repositories. Dies hat keine Auswirkung auf bestehende Indexdateien. Standardmäßig wird Indexversion 2 oder 3 verwendet. Siehe git-update-index[1] für weitere Informationen.
GIT_OBJECT_DIRECTORY: Wenn das Objektverzeichnis über diese Umgebungsvariable angegeben wird werden die SHA1-Verzeichnisse darunter angelegt, ansonsten wird standardmäßig Das Verzeichnis`$GIT_DIR/objects` verwendet.
GIT_ALTERNATE_OBJECT_DIRECTORIES: Durch die unveränderliche Natur von Git-Objekten können alte Objekte in gemeinsame schreibgeschützte Verzeichnisse archiviert werden. Diese Variable gibt eine mit ":" (";" unter Windows) getrennte Liste von Objektverzeichnissen, in denen nach Git-Objekten gesucht werden kann, an. Neue Objekte werden nicht in diese Verzeichnisse geschrieben.

Einträge, die mit " (doppelten Anführungszeichen) beginnen werden wie Zeichenketten in C interpretiert, d.h. führende und abschließende doppelte Anführungszeichen werden entfernt und Rückwärtsschrägstrich-basierte Escape-Sequenzen werden respektiert. D.h. der Wert "Pfad-mit-\"-und-:-im-Pfad":Standard-Pfad enthält zwei Pfade: "Pfad-mit-"-und-:-im-Pfad und Standard-Pfad.
GIT_DIR: Wenn die Umgebungsvariable GIT_DIR gesetzt ist, gibt sie den Pfad an, der statt .git als Basis des Repositories verwendet wird. Die Befehlszeilenoption --git-dir setzt diesen Wert auch.
GIT_WORK_TREE: Set the path to the root of the working tree. This can also be controlled by the --work-tree command-line option and the core.worktree configuration variable.
GIT_NAMESPACE: Setzt den Git Namespace; Siehe gitnamespaces[7] für Details. Die Befehlszeilenoption --namespace setzt diesen Wert auch.
GIT_CEILING_DIRECTORIES: This should be a colon-separated list of absolute paths. If set, it is a list of directories that Git should not chdir up into while looking for a repository directory (useful for excluding slow-loading network directories). It will not exclude the current working directory or a GIT_DIR set on the command line or in the environment. Normally, Git has to read the entries in this list and resolve any symlink that might be present in order to compare them with the current directory. However, if even this access is slow, you can add an empty entry to the list to tell Git that the subsequent entries are not symlinks and needn’t be resolved; e.g., GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.
GIT_DISCOVERY_ACROSS_FILESYSTEM: When run in a directory that does not have ".git" repository directory, Git tries to find such a directory in the parent directories to find the top of the working tree, but by default it does not cross filesystem boundaries. This environment variable can be set to true to tell Git not to stop at filesystem boundaries. Like GIT_CEILING_DIRECTORIES, this will not affect an explicit repository directory set via GIT_DIR or on the command line.
GIT_COMMON_DIR: Wenn diese Variable einen Pfad enthält, werden nicht-Arbeitsverzeichnis-Dateien, die sich normalerweise in $GIT_DIR befinden stattdessen aus diesem Verzeichnis geladen. Arbeitsverzeichnis-spezifische Dateien wie HEAD oder index werden aus $GIT_DIR geladen. Siehe gitrepository-layout[5] und git-worktree[1] für Details. Andere Pfadvariablen wie GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY, etc. haben Vorrang gegenüber dieser Variable.
GIT_DEFAULT_HASH: If this variable is set, the default hash algorithm for new repositories will be set to this value. This value is currently ignored when cloning; the setting of the remote repository is used instead. The default is "sha1".

Git-Commits

GIT_AUTHOR_NAME: The human-readable name used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the user.name and author.name configuration settings.
GIT_AUTHOR_EMAIL: The email address used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the user.email and author.email configuration settings.
GIT_AUTHOR_DATE: The date used for the author identity when creating commit or tag objects, or when writing reflogs. See git-commit[1] for valid formats.
GIT_COMMITTER_NAME: The human-readable name used in the committer identity when creating commit or tag objects, or when writing reflogs. Overrides the user.name and committer.name configuration settings.
GIT_COMMITTER_EMAIL: The email address used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the user.email and committer.email configuration settings.
GIT_COMMITTER_DATE: The date used for the committer identity when creating commit or tag objects, or when writing reflogs. See git-commit[1] for valid formats.
EMAIL: The email address used in the author and committer identities if no other relevant environment variable or configuration setting has been set.

Git-Diffs

GIT_DIFF_OPTS

Die einziegen gültigen Werte sind "--unified=??" oder "-u??" um die Anzahl der angezeigten Kontextzeilen zu steuern, wenn ein vereinheitlichtes Diff erstellt wird. Dies hat Vorrang vor jeglichen auf der Kommandozeile an git diff übergebenen Werten der Optionen "-U" oder "--unified".

GIT_EXTERNAL_DIFF

Wenn die Umgebungsvariable GIT_EXTERNAL_DIFF gesetzt ist, wird das darin angegebene Programm statt dem oben beschrieben Diff-Befehl aufgerufen. Für einen hinzufügten, entfernten oder modifizierten Pfad wird GIT_EXTERNAL_DIFF mit 7 Parametern aufgerufen:

Pfad alte-Datei alter-Hash alte-Rechte neue-Datei neuer-Hash neue-Rechte

wobei:

<alte|neue>-Datei

Dateien sind, die GIT_EXTERNAL_DIFF benutzen kann um den <alten|neuen> Inhalt auszulesen,

<alter|neuer>-Hash

die 40-stelligen hexadezimalen Hashes sind,

<alte|neue>-Rechte

die oktale Representation der Datei-Rechte sind.

Die Dateiparameter können auf die Arbeitsdatei des Benutzers (z.B. neue-Datei in "git-diff-files"), /dev/null (z.B. alte-Datei wenn eine neue Datei hinzugefügt wird) oder eine temporäre Datei (z.B. alte-Datei im Index) verweisen. GIT_EXTERNAL_DIFF muss sich nicht damit befassen die temporäre Datei zu löschen. --- sie wird entfernt sobald GIT_EXTERNAL_DIFF beendet wird.

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

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

GIT_DIFF_PATH_COUNTER

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

GIT_DIFF_PATH_TOTAL

Die Gesamtanzahl Pfade.

Sonstiges

GIT_MERGE_VERBOSITY: Eine numerische Angabe, die Ausgabemenge der rekursiven Merge-Strategie steuert. Überschreibt merge.verbosity. Siehe git-merge[1]
GIT_PAGER: Diese Umgebungsvariable überschreibt $PAGER. Wenn sie auf eine leere Zeichenkette oder "cat" gesetzt ist, startet Git keinen Pager. Siehe auch die Option core.pager in git-config[1].
GIT_PROGRESS_DELAY: A number controlling how many seconds to delay before showing optional progress indicators. Defaults to 2.
GIT_EDITOR: Diese Umgebungsvariable überschreibt $EDITOR und $VISUAL. Sie wird von mehreren Git-Befehlen verwendet, um im interaktiven Modus einen Editor zu öffnen. Siehe auch git-var[1] und die Option core.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 statt ssh zum Verbinden mit entfernten Systemen. Die Kommandozeilenparameter die dem konfigurierten Befehl übergeben werden, richten sich nach der SSH-Varinate. Siehe die Option ssh.variant in git-config[1] für Details.

$GIT_SSH_COMMAND hat Vorrang über $GIT_SSH und wird von der Shell interpretiert, daher können zusätzliche Argumente mit angegeben werden. GIT_SSH dagegen darf nur den Pfad zu einem Programm enthalten (dieses kann ein Wrapper-Shell-Script sein, falls zusätzliche Argumente benötigt werden).

Meistens ist es einfacher die gewünschten Optionen über Ihre persönliche .shh/config-Datei zu konfigurieren. Bitte konsultieren Sie Ihre SSH-Dokumentation für weitere Details.
GIT_SSH_VARIANT: Wenn diese Umgebungsvariable gesetzt ist, überschreibt sie Git’s automatische Erkennung ob sich GIT_SSH/GIT_SSH_COMMAND/core.sshCommand auf OpenSSH, plink oder tortoiseplink bezieht. Diese Variable überschreibt sie die Konfigurationseinstellung ssh.variant die den selben Zweck erfüllt.
GIT_ASKPASS: Wenn diese Umgebungsvariable gesetzt ist, rufen Git-Befehle die Passwörter benötigten (z.B. für HTTP- oder IMAP-Authentifizierung) dieses Programm mit geeigneten Kommandozeilenparametern auf und lesen das Passwort von seiner Standardausgabe. Siehe auch die Option core.askPass in git-config[1].
GIT_TERMINAL_PROMPT: Wenn diese Umgebungsvariable auf 0 gesetzt ist, fragt Git nicht nach Eingaben im Terminal (z.B. zur HTTP-Authentifizierung).
GIT_CONFIG_NOSYSTEM: Gibt an, ob das Auslesen der Systemweiten Konfigurationsdatei $(prefix)/etc/gitconfig übersprungen wird. Diese Umgebungsvariable kann in Kombination mit $HOME und $XDG_CONFIG_HOME genutzt werden um eine reproduzierbare Umgebung für ein Skript herzustellen oder um eine fehlerhafte /etc/gitconfig-Datei vorübergehend zu vermeiden, während man auf jemanden mit den nötigen Berechtigungen um die Fehler zu beheben wartet.
GIT_FLUSH: Wenn diese Umgebungsvariable auf 1 gesetzt ist, erzwingen Befehle wie git blame (im inkrementellen Modus),git rev-list,git log, git check-attr und git check-ignore ein Leeren des Ausgabestroms nach jedem Datensatz. Wenn diese Variable auf "0" gesetzt ist, wird die Ausgabe dieser Befehle mit vollständig gepuffertem I/O durchgeführt. Wenn diese Umgebungsvariable nicht gesetzt ist, wählt Git zwischen gepufferter oder datensatzbasierter Ausgabe basierend darauf, ob stdout in eine Datei umgeleitet zu sein scheint oder nicht.
GIT_TRACE: Aktiviert allgemeine Ablaufverfolgungsmeldungen, z.B.. Alias-Erweiterung, Ausführung von eingebauten und externen Befehlen.

Wenn diese Variable auf "1", "2" oder "true" (Vergleich ist unabhängig von Groß-/Kleinschreibung) gesetzt ist, werden Ablaufverfolgungsmeldungen nach stderr ausgegeben.

Wenn dieser Variable ein ganzzahliger Wert größer als 2 und kleiner als 10 zugewiesen ist, interpretiert Git diesen Wert als geöffneten Datei-Handle und versucht die Ablaufverfolgungsmeldungen in diese Datei zu schreiben.

Alternativ kann diese Variable auf einen absoluten Pfad (beginnt mit einem /), schreibt Git die Ablaufverfolgungsmeldungen in diese Datei.

Zurücksetzen der Variable oder setzen auf einen leeren Wert, "0" oder "false" (unabhängig von Groß-/Kleinschreibung) deaktiviert Ablaufverfolgungsmeldungen.
GIT_TRACE_FSMONITOR: Aktiviert Ablaufverfolgungsmeldungen für die Dateisystemmonitor-Erweiterung. Siehe GIT_TRACE? für verfügbare Ausgabemöglichkeiten.
GIT_TRACE_PACK_ACCESS: Aktiviert Ablaufverfolgungsmeldungen für Zugriffe auf Pakete. Für jeden Zugriff werden der Name der Paketdatei und ein Offset im Paket aufgezeichnet. Dies kann bei der Fehlersuche bei packetbezogenen Performance-Problemen hilfreich sein. Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_PACKET: Aktiviert Ablaufverfolgungsmeldungen für alle Pakete, die in und aus einem bestimmten Programm kommen. Dies kann bei der Suche nach Problemen mit der Objektaushandlung oder anderen protokollbezogenen Problemen. Die Ablaufverfolgung wird bei Packeten, die mit pack beginnen deaktiviert (Siehe hierzu GIT_TRACE_PACKFILE). Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_PACKFILE: Aktiviert die Ablaufverfolgung von gesendeten und empfangenen Packdateien eines bestimmten Programms. Im Gegensatz zu anderen Ablaufverfolgungsmeldungen ist diese Ablaufverfolgung wortgetreu: Keine Kopfzeilen und keine Umwandlung von binären Daten. Sie wollen diese Daten höchstwahrscheinlich in eine Datei umleiten (z.B. GIT_TRACE_PACKFILE=/tmp/my.pack), statt sie auf die Konsole auszugeben oder mit anderen Ablaufverfolgungsmeldungen zu vermischen.

Dies ist momentan nur für die Client-Seite der Befehle clone und fetch implementiert.
GIT_TRACE_PERFORMANCE: Aktiviert performancebezogene Ablaufverfolgungsmeldungen, z.B. gesamte Ausführunszeit jedes Git-Befehls. Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_SETUP: Enables trace messages printing the .git, working tree and current working directory after Git has completed its setup phase. See GIT_TRACE for available trace output options.
GIT_TRACE_SHALLOW: Aktiviert Ablaufverfolgungsmeldungen die zur Fehlersuche beim Anfordern (fetching)/Klonen von Repositories mit unvollständiger Historie (shallow) helfen können. Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_CURL: Enables a curl full trace dump of all incoming and outgoing data, including descriptive information, of the git transport protocol. This is similar to doing curl --trace-ascii on the command line. See GIT_TRACE for available trace output options.
GIT_TRACE_CURL_NO_DATA: Falls Curl-Ablaufverfolgung aktiviert ist (sieh GIT_TRACE_CURL oben), keine Nutzdaten, sondern nur Header und Info-Zeilen ausgegeben.
GIT_TRACE2: Enables more detailed trace messages from the "trace2" library. Output from GIT_TRACE2 is a simple text-based format for human readability.

Wenn diese Variable auf "1", "2" oder "true" (Vergleich ist unabhängig von Groß-/Kleinschreibung) gesetzt ist, werden Ablaufverfolgungsmeldungen nach stderr ausgegeben.

Wenn dieser Variable ein ganzzahliger Wert größer als 2 und kleiner als 10 zugewiesen ist, interpretiert Git diesen Wert als geöffneten Datei-Handle und versucht die Ablaufverfolgungsmeldungen in diese Datei zu schreiben.

Alternativ kann diese Variable auf einen absoluten Pfad (beginnt mit einem /), schreibt Git die Ablaufverfolgungsmeldungen in diese Datei. Falls der Pfad ein existierendes Verzeichnis ist, werden die Ablaufverfolgungsmeldungen in Dateien (eine pro Prozess), benannt nach dem letzten Teils der SID und einem optionalen Zähler (um Datienamenskollisionen zu vermeiden), in diesem Verzeichnis geschrieben.

In addition, if the variable is set to af_unix:[<socket_type>:]<absolute-pathname>, Git will try to open the path as a Unix Domain Socket. The socket type can be either stream or dgram.

Zurücksetzen der Variable oder setzen auf einen leeren Wert, "0" oder "false" (unabhängig von Groß-/Kleinschreibung) deaktiviert Ablaufverfolgungsmeldungen.

See Trace2 documentation for full details.
GIT_TRACE2_EVENT: This setting writes a JSON-based format that is suited for machine interpretation. See GIT_TRACE2 for available trace output options and Trace2 documentation for full details.
GIT_TRACE2_PERF: In addition to the text-based messages available in GIT_TRACE2, this setting writes a column-based format for understanding nesting regions. See GIT_TRACE2 for available trace output options and Trace2 documentation for full details.
GIT_TRACE_REDACT: By default, when tracing is activated, Git redacts the values of cookies, the "Authorization:" header, and the "Proxy-Authorization:" header. Set this variable to 0 to prevent this redaction.
GIT_LITERAL_PATHSPECS: Das Setzen dieser Variable auf 1 veranlasst Git alle Pfadspezifikationen buchstäblich und nicht als Glob-Muster zu interpreieren. Zum Beispiel sucht GIT_LITERAL_PATHSPECS=1 git log -- '*.c' nach Commits, die den Pfad *.c verrändern, nicht nach Dateien, die das Muster *.c betrifft. Das kann gewollt sein, wenn tatsächliche Pfade an Git übergeben werden (z.B. Pfade die von git ls-tree ausgegeben wurden oder aus Diffausgaben mit --raw o.ä. stammen).
GIT_GLOB_PATHSPECS: Das Setzen dieser Variable auf 1 veranlasst Git alle Pfadspezifikationen als Glob-Muster zu behandeln (Pfadspezifikationsangabe "glob").
GIT_NOGLOB_PATHSPECS: Das Setzen dieser Variable auf 1 veranlasst Git alle Pfadspezifikationen buchstäblich zu interpreieren (Pfadspezifikationsangabe "literal").
GIT_ICASE_PATHSPECS: Das Setzen dieser Variable auf 1 veranlasst Git bei allen Pfadspezifikationen Groß- und Kleinschreibung zu ignorieren.
GIT_REFLOG_ACTION: Wenn eine Referenz aktualisiert wird, werden Reflog-Einträge erstellt, um den Grund, dass die Referenz aktualisiert wurde (üblicherweise ist das die Bezeichnung des hochrangigen Befehls, der die Referenz aktualisiert hat), sowie den alten und neuen Wert der Referenz nachvollziehen zu können. Geskriptete Porcelain-Befehle können die Hilfsfunktion set_reflog_action in git-sh-setup um ihren Namen in diese Variable einzutragen, wenn sie vom Endbenutzer als Befehl der obersten Ebene aufgerufen werden, damit dieser im Reflog festgehalten wird.
GIT_REF_PARANOIA: If set to 1, include broken or badly named refs when iterating over lists of refs. In a normal, non-corrupted repository, this does nothing. However, enabling it may help git to detect and abort some operations in the presence of broken refs. Git sets this variable automatically when performing destructive operations like git-prune[1]. You should not need to set it yourself unless you want to be paranoid about making sure an operation has touched every ref (e.g., because you are cloning a repository to make a backup).
GIT_ALLOW_PROTOCOL: If set to a colon-separated list of protocols, behave as if protocol.allow is set to never, and each of the listed protocols has protocol.<name>.allow set to always (overriding any existing configuration). In other words, any protocol not mentioned will be disallowed (i.e., this is a whitelist, not a blacklist). See the description of protocol.allow in git-config[1] for more details.
GIT_PROTOCOL_FROM_USER: Set to 0 to prevent protocols used by fetch/push/clone which are configured to the user state. This is useful to restrict recursive submodule initialization from an untrusted repository or for programs which feed potentially-untrusted URLS to git commands. See git-config[1] for more details.
GIT_PROTOCOL: Nur zum internen Gebrauch. Wird beim Handshake des Git Wire Protokolls verwendet. Enthält eine durch Doppelpunkte : getrennte Liste von Schlüsseln mit optionalen Werten schlüssel[=wert]. Unbekannte Schlüssel und Werte müssen ignoriert werden.
GIT_OPTIONAL_LOCKS: If set to 0, Git will complete any requested operation without performing any optional sub-operations that require taking a lock. For example, this will prevent git status from refreshing the index as a side effect. This is useful for processes running in the background which do not want to cause lock contention with other operations on the repository. Defaults to 1.
GIT_REDIRECT_STDIN
GIT_REDIRECT_STDOUT
GIT_REDIRECT_STDERR: Nur unter Windows: Erlaubt es die Standardeingabe/-ausgabe/-fehlerausgabe auf die in diesen Umgebungsvariablen angegebenen Pfade umzuleiten. Dies ist besonders hilfreich bei Multithreading-Anwendungen bei denen die Standardmethode diese Datenströme mit CreateProcess() keine Option ist, da das bewirken würde, dass alle weiteren Prozesse diese erben, was reguläre Git-Operationen blockieren kann. Der Hauptanwendungsfall ist die Verwendung von benannten Pipes (z.B. \\.\pipe\my-git-stdin-123).

Es werden zwei besondere Werte unterstützt: off deaktiviert den entsprechenden Standarddatenstrom und wenn GIT_REDIRECT_STDERR auf 2>&1 gesetzt ist wird die Standardfehlerausgabe in den selben Strom wie die Standardausgabe geleitet.
GIT_PRINT_SHA1_ELLIPSIS (veraltet): If set to yes, print an ellipsis following an (abbreviated) SHA-1 value. This affects indications of detached HEADs (git-checkout[1]) and the raw diff output (git-diff[1]). Printing an ellipsis in the cases mentioned is no longer considered adequate and support for it is likely to be removed in the foreseeable future (along with the variable).

Diskussion

Mehr Details zum den folgenden Themen sind im Kapitel "Git concepts" des Benutzerhandbuchs und unter gitcore-tutorial[7] verfügbar.

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 den vollständigen Projektverlauf wiedergibt, eine „Index“-Datei, die diesen Verlauf mit dem aktuellen Inhalt des Arbeitsbereichs verknüpft und Pointer in diesem Verlauf benennt, wie z.B. Tags und Branch-Heads.

Die Objektdatenbank enthält drei Hauptarten von Objekten: Blobs, die Dateiinformationen enthalten; Trees, die auf Blobs und andere Trees verweisen, um Verzeichnisstrukturen abzubilden; und Commits, die jeweils auf einen einzelnen Tree und eine gewisse Anzahl Eltern-Commits verweisen.

Der Commit, in anderen Systemen auch „Changeset“ oder „Version“ genannt, stellt einen Schritt in der Projekthistorie dar und jeder Eltern-Commit stellt einen direkt vorhergehenden Schritt dar. Commits mit mehr als einem Eltern-Commit stellen Zusammenführungen verschiedener Entwicklungslinien dar.

Alle Objekte werden mit dem SHA1-Hash ihres Inhalts bezeichnet. Dieser wird normalerweise als 40-stellige Hexadezimalzahl angegeben. Diese Bezeichnungen sind eindeutig. Ein einzelner signierter Commit kann die gesamte Historie bis zu diesem Commit verifizieren. Zu diesem Zweck wird eine vierte Objektart, die Markierung angeboten.

Beim Erstellen werden Objekte in individuellen Dateien gespeichert, können aber aus Effizienzgründen später zusammen in sogenannten Packdateien komprimiert werden.

Benannte Zeiger, die Referenzen genannt werden, markieren interessante Punkte in der Historie. Eine Referenz kann auf ein Objekt oder eine andere Referenz verweisen. Referenzen deren Bezeichnung mit ref/head/ beginnt enthalten die SHA1-Bezeichnung de letzten Commits (der „Spitze“) eines Entwicklungszweigs. SHA1-Bezeichnungen interessanter Markierungen werden unter ref/tags/ gespeichert. Eine besondere Referenz namens HEAD verweist auf die Bezeichnung des momnentan ausgecheckten Entwicklungszweigs.

Die Indexdatei wird mit einer Liste aller Pfade, sowie pro Pfad einem Blob-Objekt und einer Reihe von Attributen initialisiert. Das Blob-Objekt repräsentiert die Inhalte der Datei gemäß der Spitze des aktuellen Entwicklungszweigs. Die Attribute (zuletzt geändert, Größe, etc.) werden von der entsprechenden Datei im Arbeitsverzeichnis genommen. Spätere Änderungen am Arbeitsverzeichnis können durch Vergleichen dieser Attribute ermittelt werden. Der Index kann mit neuen Inhalten aktualisiert werden und aus dem Inhalt des Indexes können neue Commits erstellt werden.

Der Index kann auch mehrere Einträge (genannt „Stages“) eines bestimmten Pfads enthalten. Diese Stages enthalten verschiedene noch nicht zusammengeführte Versionen einer Datei während eines Merges.

WEITERE DOKUMENTATION

Siehe die Verweise im Abschnitt „Beschreibung“ um mit der Verwendung von Git zu beginnen. Nachfolgend finden Sie vermutlich mehr Details als es für einen erstmaligen Benutzer nötig ist.

Das Kapitel „Git concepts“ des Benutzerhandbuchs und gitcore-tutorial[7] stellen eine Einführung in die zugrundeliegende Git-Architektur zur Verfügung.

Siehe gitworkflows[7] für eine Übersicht über empfohlene Arbeitsabläufe.

In den Howto-Dokumenten finden Sie nützliche Beispiele.

Die Interna sind in der Git-API-Dokumentation dokumentiert.

Für Benutzer, die von CVS migrieren könnte auch gitcvs-migration[7] interessant sein.

Autoren

Git wurde ursprünglich von Linus Torvalds geschrieben und wird jetzt von Junio C Hamano weitergeführt. Zahlreiche Beiträge sind über die Git-E-Mail-Verteilerliste <git@vger.kernel.org> entstanden. Unter http://www.openhub.net/p/git/contributors/summary steht eine etwas vollständigere Liste der Mitwirkenden bereit.

Wenn sie einen Klon von git.git haben, können Sie sich mit git-shortlog[1] und git-blame[1] die Urheber einzelner Projektteile anzeigen lassen.

Fehler melden

Report bugs to the Git mailing list <git@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there. See the list archive at https://lore.kernel.org/git for previous bug reports and other discussions.

Sicherheitsrelevante Fehler sollten vetraulich an die Git-Sicherheits-E-Mail-Verteilerliste <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]

Teil der git[1] Suite

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands