Über den "alternates"-Mechanismus kann ein Repository einen Teil seiner Objekt-Datenbank von einer anderen Objekt-Datenbank erben, die als "Alternative" bezeichnet wird.

Ein Bare-Repository ist normalerweise ein passend benanntes Verzeichnis mit der Suffix ".git", das keine lokal ausgecheckte Kopie der Dateien unter Versionskontrolle enthält. Das bedeutet, dass alle Git-Administrations- und Steuerdateien, die normalerweise im versteckten Unterverzeichnis ".git" vorhanden wären, stattdessen direkt im Verzeichnis "repository.git" vorhanden sind und keine anderen Dateien vorhanden oder ausgecheckt sind. Üblicherweise stellen Herausgeber öffentlicher Repositories Bare-Repositories zur Verfügung.

Nicht typisiertes Objekt, z. B. der Inhalt einer Datei.

Ein "Branch" ist eine Entwicklungslinie. Der letzte Commit in einem Branch wird als Spitze dieses Branches bezeichnet. Die Spitze des Branches wird durch einen Branch-Head referenziert, der sich vorwärts bewegt, wenn zusätzliche Entwicklung auf dem Branch durchgeführt wird. Ein einzelnes Git-Repository kann eine beliebige Anzahl von Branches verfolgen, aber Ihr Arbeitsverzeichnis ist nur mit einem davon ("aktueller" oder "ausgecheckter" Branch) verbunden, und HEAD zeigt auf diesen Branch.

Veraltet für: Index.

Eine Liste von Objekten, wobei jedes Objekt in der Liste einen Verweis auf seinen Nachfolger enthält (z. B. könnte der Nachfolger eines Commits eines seiner Eltern sein).

BitKeeper/cvsps-Sprache für "Commit". Da Git keine Änderungen, sondern Zustände speichert, ergibt die Verwendung des Begriffs "Änderungssätze" bei Git keinen Sinn.

Die Aktion, alle oder Teile des Arbeitsverzeichnisses mit einem Baumobjekt oder Blob aus der Objekt-Datenbank zu aktualisieren und den Index und HEAD zu aktualisieren, wenn das gesamte Arbeitsverzeichnis auf einen neuen Branch gezeigt hat.

Im SCM-Jargon bedeutet "Cherry Pick", eine Teilmenge von Änderungen aus einer Reihe von Änderungen (typischerweise Commits) auszuwählen und sie als neue Reihe von Änderungen auf einer anderen Codebasis aufzuzeichnen. In Git wird dies durch den Befehl "git cherry-pick" durchgeführt, um die von einem vorhandenen Commit eingeführte Änderung zu extrahieren und sie basierend auf der Spitze des aktuellen Branches als neuen Commit aufzuzeichnen.

Ein Arbeitsverzeichnis ist "sauber", wenn es mit der vom aktuellen Head referenzierten Revision übereinstimmt. Siehe auch "dirty".

Als Substantiv: Ein einzelner Punkt in der Git-Historie; die gesamte Historie eines Projekts wird als eine Menge von zusammenhängenden Commits dargestellt. Das Wort "Commit" wird von Git oft an denselben Stellen verwendet, an denen andere Versionskontrollsysteme die Wörter "Revision" oder "Version" verwenden. Wird auch als Kurzform für Commit-Objekt verwendet.

Ein Synonym für die DAG-Struktur, die durch die Commits in der Objekt-Datenbank gebildet wird und durch die Spitzen der Branches referenziert wird, wobei die Kette der verknüpften Commits verwendet wird. Diese Struktur ist der definitive Commit-Graph. Der Graph kann auf andere Weise dargestellt werden, z. B. als "Commit-Graph-Datei".

Die "Commit-Graph"-Datei (normalerweise mit Bindestrich) ist eine ergänzende Darstellung des Commit-Graphen, die das Durchlaufen des Commit-Graphen beschleunigt. Die "Commit-Graph"-Datei wird entweder im Verzeichnis .git/objects/info oder im info-Verzeichnis einer alternativen Objekt-Datenbank gespeichert.

Ein Objekt, das die Informationen über eine bestimmte Revision enthält, wie z. B. Eltern, Committer, Autor, Datum und das Baumobjekt, das dem obersten Verzeichnis der gespeicherten Revision entspricht.

Ein Commit-Objekt oder ein Objekt, das rekursiv zu einem Commit-Objekt dereferenziert werden kann. Die folgenden sind alle Commit-ishes: ein Commit-Objekt, ein Tag-Objekt, das auf ein Commit-Objekt zeigt, ein Tag-Objekt, das auf ein Tag-Objekt zeigt, das auf ein Commit-Objekt zeigt, usw.

Grundlegende Datenstrukturen und Dienstprogramme von Git. Bietet nur begrenzte Werkzeuge zur Quellcodeverwaltung.

Gerichteter azyklischer Graph. Die Commit-Objekte bilden einen gerichteten azyklischen Graphen, da sie Eltern (gerichtet) haben und der Graph der Commit-Objekte azyklisch ist (es gibt keine Kette, die mit demselben Objekt beginnt und endet).

Ein unerreichbares Objekt, das auch von anderen unerreichbaren Objekten nicht erreichbar ist; ein hängendes Objekt hat keine Verweise von Referenzen oder Objekten im Repository.

Bezieht sich auf eine symbolische Referenz: die Aktion, auf die Referenz zuzugreifen, auf die eine symbolische Referenz zeigt. Rekursives Dereferenzieren beinhaltet die wiederholte Ausführung des oben genannten Prozesses auf der resultierenden Referenz, bis eine nicht-symbolische Referenz gefunden wird.

Normalerweise speichert HEAD den Namen eines Branches, und Befehle, die auf die von HEAD repräsentierte Historie wirken, arbeiten auf der Historie, die zur Spitze des Branches führt, auf den HEAD zeigt. Git erlaubt es Ihnen jedoch auch, einen beliebigen Commit auszuchecken, der nicht unbedingt die Spitze eines bestimmten Branches ist. Der HEAD in einem solchen Zustand wird als "detached" bezeichnet.

Die Liste, die Sie mit "ls" erhalten :-)

Ein Arbeitsverzeichnis wird als "dirty" bezeichnet, wenn es Änderungen enthält, die noch nicht auf den aktuellen Branch committet wurden.

Ein böses Merge ist ein Merge, der Änderungen einführt, die in keinem Elternteil vorkommen.

Ein Fast-Forward ist eine spezielle Art von Merge, bei dem Sie eine Revision haben und Änderungen von einem anderen Branch "mergen", die zufällig ein Nachfahre dessen sind, was Sie haben. In einem solchen Fall erstellen Sie keinen neuen Merge-Commit, sondern aktualisieren lediglich Ihren Branch, damit er auf dieselbe Revision wie der Branch zeigt, den Sie mergen. Dies geschieht häufig bei einem Remote-Tracking-Branch eines Remote-Repositorys.

Das Abrufen eines Branches bedeutet, den Head-Referenz des Branches aus einem Remote-Repository abzurufen, herauszufinden, welche Objekte in der lokalen Objekt-Datenbank fehlen, und diese ebenfalls abzurufen. Siehe auch git-fetch[1].

Linus Torvalds entwarf Git ursprünglich als Dateisystem im User-Space, d. h. als Infrastruktur zum Speichern von Dateien und Verzeichnissen. Dies stellte die Effizienz und Geschwindigkeit von Git sicher.

Synonym für Repository (für Archiv-Leute).

Eine einfache Datei ".git" am Stammverzeichnis eines Arbeitsverzeichnisses, die auf das Verzeichnis verweist, das das eigentliche Repository ist. Für die richtige Verwendung siehe git-worktree[1] oder git-submodule[1]. Für die Syntax siehe gitrepository-layout[5].

Grafts ermöglichen es, zwei ansonsten unterschiedliche Entwicklungslinien zu verbinden, indem gefälschte Ahneninformationen für Commits aufgezeichnet werden. Auf diese Weise können Sie Git dazu bringen, so zu tun, als ob die Menge der Eltern eines Commits anders ist als die, die bei der Erstellung des Commits aufgezeichnet wurde. Konfiguriert über die Datei .git/info/grafts.

Im Kontext von Git ein Synonym für Objektname.

Eine benannte Referenz auf den Commit an der Spitze eines Branches. Heads werden in einer Datei im Verzeichnis $GIT_DIR/refs/heads/ gespeichert, außer bei Verwendung von Packed Refs. (Siehe git-pack-refs[1].)

Der aktuelle Branch. Genauer gesagt: Ihr Arbeitsverzeichnis wird normalerweise aus dem Zustand des Baums abgeleitet, auf den HEAD verweist. HEAD ist eine Referenz auf einen der Heads in Ihrem Repository, außer bei Verwendung eines detached HEAD, in diesem Fall verweist er direkt auf einen beliebigen Commit.

Ein Synonym für Head.

Während der normalen Ausführung mehrerer Git-Befehle werden optionale Skripte aufgerufen, die es einem Entwickler ermöglichen, Funktionalität oder Überprüfungen hinzuzufügen. Typischerweise ermöglichen Hooks, dass ein Befehl vorab überprüft und potenziell abgebrochen werden kann, und ermöglichen eine Benachrichtigung nach Abschluss des Vorgangs. Die Hook-Skripte befinden sich im Verzeichnis $GIT_DIR/hooks/ und werden aktiviert, indem einfach das Suffix ".sample" aus dem Dateinamen entfernt wird. In früheren Versionen von Git mussten Sie diese ausführbar machen.

Eine Sammlung von Dateien mit Stat-Informationen, deren Inhalte als Objekte gespeichert werden. Der Index ist eine gespeicherte Version Ihres Arbeitsverzeichnisses. Tatsächlich kann er auch eine zweite und sogar eine dritte Version eines Arbeitsverzeichnisses enthalten, die beim Mergen verwendet werden.

Die Informationen zu einer bestimmten Datei, die im Index gespeichert sind. Ein Index-Eintrag kann unvermischt sein, wenn ein Merge gestartet, aber noch nicht abgeschlossen wurde (d. h. wenn der Index mehrere Versionen dieser Datei enthält).

Der Standard-Entwicklungs-Branch. Jedes Mal, wenn Sie ein Git-Repository erstellen, wird ein Branch namens "master" erstellt und zum aktiven Branch. In den meisten Fällen enthält dieser die lokale Entwicklung, obwohl das rein konventionell ist und nicht vorgeschrieben.

Als Verb: Die Inhalte eines anderen Branches (möglicherweise aus einem externen Repository) in den aktuellen Branch zu integrieren. Wenn der gemergte Branch aus einem anderen Repository stammt, geschieht dies durch zuerst das Abrufen (fetching) des Remote-Branches und dann das Mergen des Ergebnisses in den aktuellen Branch. Diese Kombination aus Fetch- und Merge-Vorgängen wird als Pull bezeichnet. Das Mergen wird durch einen automatischen Prozess durchgeführt, der Änderungen identifiziert, die seit der Abzweigung der Branches vorgenommen wurden, und dann alle diese Änderungen zusammen anwendet. In Fällen, in denen Änderungen zu Konflikten führen, kann eine manuelle Intervention erforderlich sein, um den Merge abzuschließen.

Die Speichereinheit in Git. Es wird eindeutig durch den SHA-1 seines Inhalts identifiziert. Folglich kann ein Objekt nicht geändert werden.

Speichert eine Menge von "Objekten", und ein einzelnes Objekt wird durch seinen Objektnamen identifiziert. Die Objekte befinden sich normalerweise in $GIT_DIR/objects/.

Synonym für Objektname.

Der eindeutige Identifikator eines Objekts. Der Objektname wird normalerweise durch eine 40 Zeichen lange Hexadezimalzeichenkette dargestellt. Umgangssprachlich auch als SHA-1 bezeichnet.

Einer der Identifikatoren "Commit", "Tree", "Tag" oder "Blob", der den Typ eines Objekts beschreibt.

Mehr als zwei Branches mergen.

Die Handlung, auf einen Branch zu wechseln, der noch nicht existiert (d. h. ein ungeborener Branch). Nach einer solchen Operation wird der zuerst erstellte Commit zu einem Commit ohne Elternteil, was eine neue Historie beginnt.

Das Standard-Upstream-Repository. Die meisten Projekte haben mindestens ein Upstream-Projekt, das sie verfolgen. Standardmäßig wird *origin* zu diesem Zweck verwendet. Neue Upstream-Updates werden in die Remote-Tracking-Branches namens origin/name-des-upstream-branch geholt, die Sie mit git branch -r anzeigen können.

Nur Dateien im Arbeitsverzeichnis aktualisieren und hinzufügen, aber nicht löschen, ähnlich wie *cp -R* den Inhalt im Zielverzeichnis aktualisieren würde. Dies ist der Standardmodus bei einem Checkout, wenn Dateien aus dem Index oder einem Tree-ish ausgecheckt werden. Im Gegensatz dazu löscht der No-Overlay-Modus auch verfolgte Dateien, die nicht in der Quelle vorhanden sind, ähnlich wie *rsync --delete*.

Eine Sammlung von Objekten, die in einer einzigen Datei komprimiert wurden (um Platz zu sparen oder sie effizient zu übertragen).

Die Liste von Identifikatoren und anderen Informationen der Objekte in einem Pack, um den effizienten Zugriff auf den Inhalt eines Packs zu erleichtern.

Muster zur Einschränkung von Pfaden in Git-Befehlen.

Ein Commit-Objekt enthält eine (möglicherweise leere) Liste der logischen Vorgänger im Entwicklungsstrang, d. h. seiner Eltern.

Die Aktion des rekursiven Dereferenzierens eines Tag-Objekts.

Der Begriff Pickaxe bezieht sich auf eine Option der Diffcore-Routinen, die hilft, Änderungen auszuwählen, die eine bestimmte Textzeichenkette hinzufügen oder löschen. Mit der Option --pickaxe-all kann es verwendet werden, um den gesamten Änderungssatz anzuzeigen, der z. B. eine bestimmte Textzeile eingeführt oder entfernt hat. Siehe git-diff[1].

Ein niedlicher Name für Core Git.

Ein niedlicher Name für Programme und Programmsuiten, die auf Core Git aufbauen und einen hochrangigen Zugriff auf Core Git bieten. Porcelains bieten mehr eine SCM-Schnittstelle als das Plumbing.

Referenzen, die pro Arbeitsverzeichnis gelten, anstatt global. Dies sind derzeit nur HEAD und alle Referenzen, die mit refs/bisect/ beginnen, können aber später auch andere ungewöhnliche Referenzen umfassen.

Eine Referenz, die andere Semantik als normale Referenzen hat. Diese Referenzen können über normale Git-Befehle gelesen werden, aber nicht mit Befehlen wie git-update-ref[1] geschrieben werden.

Einen Branch zu ziehen bedeutet, ihn abzurufen und zu mergen. Siehe auch git-pull[1].

Einen Branch zu pushen bedeutet, die Head-Referenz des Branches aus einem Remote-Repository abzurufen, zu prüfen, ob sie ein Vorfahre der lokalen Head-Referenz des Branches ist, und in diesem Fall alle Objekte, die von der lokalen Head-Referenz erreichbar sind und die im Remote-Repository fehlen, in die Remote-Objekt-Datenbank zu legen und die Remote-Head-Referenz zu aktualisieren. Wenn der Remote-Head kein Vorfahre des lokalen Heads ist, schlägt der Push fehl.

Alle Vorfahren eines gegebenen Commits gelten als von diesem Commit "erreichbar". Allgemeiner gesagt ist ein Objekt von einem anderen erreichbar, wenn wir von einem zum anderen durch eine Kette gelangen können, die Tags zu dem verfolgt, was sie taggen, Commits zu ihren Eltern oder Bäumen und Bäume zu den Bäumen oder Blobs, die sie enthalten.

Erreichbarkeits-Bitmaps speichern Informationen über die Erreichbarkeit eines ausgewählten Satzes von Commits in einem Packfile oder einem Multi-Pack-Index (MIDX), um die Objektsuche zu beschleunigen. Die Bitmaps werden in einer ".bitmap"-Datei gespeichert. Ein Repository kann höchstens eine Bitmap-Datei verwenden. Die Bitmap-Datei kann entweder zu einem Pack oder zum Multi-Pack-Index des Repositorys gehören (falls vorhanden).

Eine Reihe von Änderungen aus einem Branch auf einer anderen Basis neu anzuwenden und den Head dieses Branches auf das Ergebnis zurückzusetzen.

Ein Name, der auf einen Objektnamen oder eine andere Referenz zeigt (letztere wird als symbolische Referenz bezeichnet). Der Einfachheit halber kann eine Referenz bei der Verwendung als Argument für einen Git-Befehl manchmal abgekürzt werden; siehe gitrevisions[7] für Details. Referenzen werden im Repository gespeichert.

Ein Reflog zeigt die lokale "Historie" einer Referenz. Mit anderen Worten, es kann Ihnen sagen, was die 3. letzte Revision in *diesem* Repository war und was gestern um 21:14 Uhr der aktuelle Zustand in *diesem* Repository war. Einzelheiten finden Sie unter git-reflog[1].

Ein "Refspec" wird von fetch und push verwendet, um die Zuordnung zwischen Remote-Referenzen Referenz und lokalen Referenzen zu beschreiben. Einzelheiten finden Sie unter git-fetch[1] oder git-push[1].

Ein Repository, das zur Nachverfolgung desselben Projekts verwendet wird, aber woanders residiert. Zur Kommunikation mit Remotes siehe fetch oder push.

Eine Referenz, die verwendet wird, um Änderungen von einem anderen Repository zu verfolgen. Sie sieht typischerweise so aus: refs/remotes/foo/bar (was darauf hindeutet, dass sie einen Branch namens bar in einem Remote namens foo verfolgt) und entspricht der rechten Seite eines konfigurierten Fetch-Refspecs Refspec. Ein Remote-Tracking-Branch sollte keine direkten Modifikationen enthalten oder lokale Commits darauf gemacht haben.

Eine Sammlung von Referenzen zusammen mit einer Objektdatenbank, die alle Objekte enthält, die von den Referenzen erreichbar sind, möglicherweise ergänzt durch Metadaten aus einem oder mehreren Porcelains. Ein Repository kann eine Objektdatenbank über den Mechanismus Alternates mit anderen Repositories teilen.

Die Aktion, manuell zu beheben, was ein fehlgeschlagener automatischer Merge hinterlassen hat.

Synonym für Commit (das Nomen).

Teile der Entwicklung verwerfen, d.h. den Head auf eine frühere Revision setzen.

Source Code Management (Werkzeug).

"Secure Hash Algorithm 1"; eine kryptografische Hash-Funktion. Im Kontext von Git als Synonym für Objektname verwendet.

Größtenteils ein Synonym für Shallow Repository, aber der Ausdruck macht deutlicher, dass es durch Ausführen des Befehls git clone --depth=... erstellt wurde.

Ein flaches Repository hat eine unvollständige Historie, von der einige Commits ihre Eltern "verätzt" haben (mit anderen Worten, Git wird angewiesen, so zu tun, als hätten diese Commits keine Eltern, obwohl sie im Commit-Objekt aufgezeichnet sind). Dies ist manchmal nützlich, wenn Sie nur an der jüngsten Historie eines Projekts interessiert sind, obwohl die tatsächliche Historie, die im Upstream aufgezeichnet ist, viel größer ist. Ein flaches Repository wird erstellt, indem die Option --depth an git-clone[1] übergeben wird, und seine Historie kann später mit git-fetch[1] vertieft werden.

Ein Objekt, das verwendet wird, um den Inhalt eines unsauberen Arbeitsverzeichnisses und des Index für die zukünftige Wiederverwendung vorübergehend zu speichern.

Ein Repository, das die Historie eines separaten Projekts innerhalb eines anderen Repositorys enthält (letzteres wird als Superprojekt bezeichnet).

Ein Repository, das Repositories anderer Projekte in seinem Arbeitsbaum als Submodule referenziert. Das Superprojekt kennt die Namen von (hält aber keine Kopien davon) Commit-Objekten der enthaltenen Submodule.

Symbolische Referenz: Anstatt die SHA-1-ID selbst zu enthalten, hat sie das Format ref: refs/some/thing und wird beim Referenzieren rekursiv zu dieser Referenz dereferenziert. HEAD ist ein Paradebeispiel für eine symbolische Referenz. Symbolische Referenzen werden mit dem Befehl git-symbolic-ref[1] manipuliert.

Eine Referenz im Namensraum refs/tags/, die auf ein Objekt eines beliebigen Typs zeigt (typischerweise zeigt ein Tag entweder auf ein Tag-Objekt oder ein Commit-Objekt). Im Gegensatz zu einem Head wird ein Tag nicht durch den Befehl commit aktualisiert. Ein Git-Tag hat nichts mit einem Lisp-Tag zu tun (das im Git-Kontext als Objekttyp bezeichnet würde). Ein Tag wird typischerweise verwendet, um einen bestimmten Punkt in der Commit-Abstammungskette Kette zu markieren.

Ein Objekt, das eine Referenz enthält, die auf ein anderes Objekt zeigt, welches eine Nachricht wie ein Commit-Objekt enthalten kann. Es kann auch eine (PGP-)Signatur enthalten, in diesem Fall wird es als "signiertes Tag-Objekt" bezeichnet.

Ein regulärer Git Branch, der von einem Entwickler verwendet wird, um eine konzeptionelle Entwicklungslinie zu identifizieren. Da Branches sehr einfach und kostengünstig sind, ist es oft wünschenswert, mehrere kleine Branches zu haben, die jeweils sehr gut definierte Konzepte oder kleine inkrementelle, aber verwandte Änderungen enthalten.

Schlüssel-Wert-Metadaten. Trailer finden sich optional am Ende einer Commit-Nachricht. Können in anderen Communities auch als "Footer" oder "Tags" bezeichnet werden. Siehe git-interpret-trailers[1].

Entweder ein Arbeitsbaum oder ein Tree-Objekt zusammen mit den abhängigen Blob- und Tree-Objekten (d.h. eine gespeicherte Darstellung eines Arbeitsbaums).

Ein Objekt, das eine Liste von Dateinamen und Modi zusammen mit Referenzen auf die zugehörigen Blob- und/oder Tree-Objekte enthält. Ein Tree ist gleichbedeutend mit einem Verzeichnis.

Ein Tree-Objekt oder ein Objekt, das rekursiv zu einem Tree-Objekt dereferenziert werden kann. Das Dereferenzieren eines Commit-Objekts ergibt das Tree-Objekt, das dem obersten Verzeichnis der Revision entspricht. Die folgenden sind alle Tree-ishes: ein Commit-ish, ein Tree-Objekt, ein Tag-Objekt, das auf ein Tree-Objekt zeigt, ein Tag-Objekt, das auf ein Tag-Objekt zeigt, das auf ein Tree-Objekt zeigt, usw.

Der HEAD kann auf einen Branch zeigen, der noch nicht existiert und auf dem noch kein Commit vorhanden ist; ein solcher Branch wird als ungeborener Branch bezeichnet. Die typischste Art, wie Benutzer auf einen ungeborenen Branch stoßen, ist die Neuerstellung eines Repositorys, ohne von woanders zu klonen. Der HEAD würde auf den main (oder master, je nach Konfiguration) Branch zeigen, der noch geboren werden muss. Auch einige Operationen können Sie mit ihrer Orphan-Option auf einen ungeborenen Branch bringen.

Ein Index, der ungemergte Index-Einträge enthält.

Ein Objekt, das von keinem Branch, Tag oder einer anderen Referenz erreichbar ist.

Der Standard- Branch, der in den fraglichen Branch gemergt wird (oder auf den der fragliche Branch gerebased wird). Er wird über branch.<name>.remote und branch.<name>.merge konfiguriert. Wenn der Upstream-Branch von *A* origin/B ist, sagen wir manchmal "A verfolgt origin/B".

Der Baum der tatsächlich ausgecheckten Dateien. Der Arbeitsbaum enthält normalerweise den Inhalt des Trees des HEAD-Commits plus alle lokalen Änderungen, die Sie vorgenommen, aber noch nicht committet haben.

Ein Repository kann null (d.h. ein Bare-Repository) oder ein oder mehrere Worktrees haben, die daran angehängt sind. Ein "Worktree" besteht aus einem "Arbeitsbaum" und Repository-Metadaten, von denen die meisten mit anderen Worktrees eines einzelnen Repositorys geteilt werden, und einige davon werden pro Worktree separat verwaltet (z. B. der Index, HEAD und Pseudoreferenzen wie MERGE_HEAD, pro-Worktree-Referenzen und pro-Worktree-Konfigurationsdatei).