Wenn sich das zu klonende Repository auf einem lokalen Rechner befindet, umgeht diese Option den normalen "Git-fähigen" Transportmechanismus und klont das Repository, indem es eine Kopie von HEAD und allem unter den Verzeichnissen objects und refs erstellt. Die Dateien unter dem Verzeichnis .git/objects/ werden nach Möglichkeit hartverknüpft, um Speicherplatz zu sparen.

Erzwingt, dass der Klonvorgang von einem Repository auf einem lokalen Dateisystem die Dateien im Verzeichnis .git/objects kopiert, anstatt Hardlinks zu verwenden. Dies kann wünschenswert sein, wenn Sie ein Backup Ihres Repositorys erstellen möchten.

Wenn sich das zu klonende Repository auf dem lokalen Rechner befindet, wird anstelle der Verwendung von Hardlinks automatisch .git/objects/info/alternates eingerichtet, um die Objekte mit dem Quell-Repository zu teilen. Das resultierende Repository beginnt ohne eigene Objekte.

Wenn sich die Referenz <repository> auf dem lokalen Rechner befindet, wird automatisch .git/objects/info/alternates eingerichtet, um Objekte aus der Referenz <repository> zu beziehen. Die Verwendung eines bereits vorhandenen Repositorys als Alternativquelle erfordert weniger Objekte, die vom zu klonenden Repository kopiert werden müssen, was die Netzwerk- und lokalen Speicherkosten reduziert. Bei Verwendung von --reference-if-able wird ein nicht vorhandenes Verzeichnis mit einer Warnung übersprungen, anstatt den Klon abzubrechen.

Leihen Sie sich die Objekte von mit den --reference Optionen angegebenen Referenz-Repositorys nur zur Reduzierung der Netzwerkübertragung aus und hören Sie auf, von ihnen zu leihen, nachdem ein Klon erstellt wurde, indem Sie die notwendigen lokalen Kopien der geliehenen Objekte erstellen. Diese Option kann auch beim lokalen Klonen von einem Repository verwendet werden, das bereits Objekte von einem anderen Repository leiht — das neue Repository wird Objekte vom selben Repository leihen, und diese Option kann verwendet werden, um das Leihen zu beenden.

Leise arbeiten. Der Fortschritt wird nicht auf dem Standardfehlerausgabestrom berichtet.

Ausführlich ausführen. Beeinflusst nicht die Berichterstattung des Fortschrittsstatus auf dem Standardfehlerausgabestrom.

Der Fortschrittsstatus wird standardmäßig auf dem Standardfehlerausgabestrom berichtet, wenn dieser mit einem Terminal verbunden ist, es sei denn, --quiet wird angegeben. Diese Option erzwingt den Fortschrittsstatus auch dann, wenn der Standardfehlerausgabestrom nicht auf ein Terminal umgeleitet wird.

Überträgt die angegebene Zeichenkette an den Server bei der Kommunikation über Protokollversion 2. Die angegebene Zeichenkette darf kein NUL- oder LF-Zeichen enthalten. Die Behandlung von Serveroptionen durch den Server, einschließlich unbekannter, ist serverspezifisch. Wenn mehrere --server-option=<option> angegeben werden, werden sie alle in der auf der Befehlszeile angegebenen Reihenfolge an die Gegenseite gesendet. Wenn von der Befehlszeile keine --server-option=<option> angegeben wird, werden stattdessen die Werte der Konfigurationsvariable remote.<name>.serverOption verwendet.

Nach Abschluss des Klons wird kein Checkout von HEAD durchgeführt.

Schlägt fehl, wenn das Quell-Repository ein flaches Repository ist. Die Konfigurationsvariable clone.rejectShallow kann verwendet werden, um die Standardeinstellung festzulegen.

Erstellt ein *bare* Git-Repository. Das heißt, anstatt <directory> zu erstellen und die Verwaltungsdateien in <directory>/.git abzulegen, wird <directory> selbst zum $GIT_DIR. Dies impliziert offensichtlich --no-checkout, da es keinen Ort gibt, an dem der Arbeitsbaum ausgecheckt werden kann. Auch die Branch-Heads im Remote werden direkt zu entsprechenden lokalen Branch-Heads kopiert, ohne sie nach refs/remotes/origin/ zu mappen. Wenn diese Option verwendet wird, werden weder Remote-Tracking-Zweige noch die zugehörigen Konfigurationsvariablen erstellt.

Verwendet einen Sparse-Checkout, bei dem zunächst nur Dateien im obersten Verzeichnis vorhanden sind. Der Befehl git-sparse-checkout[1] kann verwendet werden, um das Arbeitsverzeichnis bei Bedarf zu erweitern.

Verwendet die partielle Klonfunktion und fordert den Server auf, eine Teilmenge der erreichbaren Objekte gemäß einem gegebenen Objektfilter zu senden. Bei Verwendung von --filter wird der angegebene <filter-spec> für den Filter des partiellen Klons verwendet. Zum Beispiel filtert --filter=blob:none alle Blobs (Dateiinhalte) heraus, bis sie von Git benötigt werden. Ebenso filtert --filter=blob:limit=<size> alle Blobs heraus, deren Größe mindestens <size> beträgt. Weitere Details zu Filter-Spezifikationen finden Sie in der Option --filter in git-rev-list[1].

Wendet den Filter für partielle Klone auch auf alle Submodule im Repository an. Erfordert --filter und --recurse-submodules. Dies kann durch Setzen der Konfigurationsoption clone.filterSubmodules standardmäßig aktiviert werden.

Richtet einen Spiegel des Quell-Repositorys ein. Dies impliziert --bare. Im Vergleich zu --bare bildet --mirror nicht nur lokale Zweige der Quelle auf lokale Zweige des Ziels ab, sondern bildet alle Refs (einschließlich Remote-Tracking-Zweige, Notizen usw.) ab und richtet eine Ref-Spezifikation ein, sodass alle diese Refs durch ein git remote update im Ziel-Repository überschrieben werden.

Anstatt des Remote-Namens origin zu verwenden, um das Upstream-Repository zu verfolgen, wird <name> verwendet. Überschreibt clone.defaultRemoteName aus der Konfiguration.

Anstatt HEAD auf den Zweig zu setzen, auf den der HEAD des geklonten Repositorys zeigt, wird stattdessen auf den <name>-Zweig gezeigt. In einem nicht-bare Repository ist dies der Zweig, der ausgecheckt wird. --branch kann auch Tags übernehmen und den HEAD an diesem Commit im resultierenden Repository abkoppeln.

Erstellt ein neues Repository und holt nur die Historie, die zu der angegebenen Revision <rev> führt, ohne einen Remote-Tracking-Zweig zu erstellen, ohne einen lokalen Zweig zu erstellen und den HEAD auf <rev> abzukoppeln. Das Argument kann ein Ref-Name sein (z. B. refs/heads/main oder refs/tags/v1.0), der zu einem Commit abgerollt wird, oder ein hexadezimaler Objektname. Diese Option ist inkompatibel mit --branch und --mirror.

Wenn angegeben und das zu klonende Repository über ssh angesprochen wird, gibt dies einen nicht standardmäßigen Pfad für den auf der Gegenseite ausgeführten Befehl an.

Gibt das Verzeichnis an, aus dem Vorlagen verwendet werden sollen; (siehe Abschnitt "TEMPLATE DIRECTORY" von git-init[1].)

Setzt eine Konfigurationsvariable im neu erstellten Repository; dies wird sofort wirksam, nachdem das Repository initialisiert wurde, aber bevor die Remote-Historie abgerufen oder Dateien ausgecheckt wurden. Der <key> hat das gleiche Format wie von git-config[1] erwartet (z. B. core.eol=true). Wenn mehrere Werte für denselben Schlüssel angegeben werden, wird jeder Wert in die Konfigurationsdatei geschrieben. Dies macht es beispielsweise sicher, zusätzliche Fetch-Refspecs zum Origin-Remote hinzuzufügen.

Erstellt einen *shallow* Clone mit einer Historie, die auf die angegebene Anzahl von Commits gekürzt ist. Impliziert --single-branch, es sei denn, --no-single-branch wird angegeben, um die Historien nahe der Spitzen aller Zweige abzurufen. Wenn Sie Submodule flach klonen möchten, übergeben Sie auch --shallow-submodules.

Erstellt einen flachen Clone mit einer Historie nach dem angegebenen Zeitpunkt.

Erstellt einen flachen Clone mit einer Historie, die Commits ausschließt, die von einem angegebenen Remote-Zweig oder Tag erreichbar sind. Diese Option kann mehrmals angegeben werden.

Klonen Sie nur die Historie, die zur Spitze eines einzelnen Zweigs führt, entweder angegeben durch die Option --branch oder den primären Zweig, auf den der Remote-HEAD zeigt. Weitere Fetches in das resultierende Repository aktualisieren nur den Remote-Tracking-Zweig für den Zweig, für den diese Option beim anfänglichen Klonen verwendet wurde. Wenn der HEAD im Remote beim --single-branch Klon nicht auf einen Zweig zeigte, wird kein Remote-Tracking-Zweig erstellt.

Steuert, ob Tags geklont werden sollen oder nicht. Wenn --no-tags angegeben wird, wird die Option permanent, indem die Konfiguration remote.<remote>.tagOpt=--no-tags gesetzt wird. Dies stellt sicher, dass zukünftige git pull und git fetch keinen Tags folgen werden. Explizite Tag-Fetches werden weiterhin funktionieren (siehe git-fetch[1]).

Nachdem der Klon erstellt wurde, werden Submodule basierend auf dem angegebenen <pathspec> initialisiert und geklont. Wenn kein =<pathspec> angegeben wird, werden alle Submodule initialisiert und geklont. Diese Option kann mehrmals für Pfadangaben, die aus mehreren Einträgen bestehen, angegeben werden. Der resultierende Klon hat submodule.active auf die angegebene Pfadangabe gesetzt, oder "." (bedeutet alle Submodule), wenn keine Pfadangabe angegeben wurde.

Alle geklonten Submodule werden flach mit einer Tiefe von 1 sein.

Alle geklonten Submodule verwenden den Status des Remote-Tracking-Zweigs des Submoduls, um das Submodul zu aktualisieren, anstatt den vom Superprojekt aufgezeichneten SHA-1. Entspricht dem Übergeben von --remote an git submodule update.

Anstatt das geklonte Repository dort abzulegen, wo es hingehört, wird das geklonte Repository im angegebenen Verzeichnis abgelegt und dann ein dateisystem-unabhängiger Git-Symbollink dorthin erstellt. Das Ergebnis ist, dass das Git-Repository vom Arbeitsbaum getrennt werden kann.

Gibt das angegebene Ref-Speicherformat für das Repository an. Die gültigen Werte sind

Die Anzahl der gleichzeitig abgerufenen Submodule. Standard ist die Option submodule.fetchJobs.

Das (möglicherweise entfernte) <repository>, das geklont werden soll. Siehe den Abschnitt GIT URLS unten für weitere Informationen zur Angabe von Repositorys.

Der Name eines neuen Verzeichnisses, in das geklont werden soll. Der "humanish"-Teil des Quell-Repositorys wird verwendet, wenn kein <directory> explizit angegeben wird (repo für /path/to/repo.git und foo für host.xz:foo/.git). Das Klonen in ein vorhandenes Verzeichnis ist nur erlaubt, wenn das Verzeichnis leer ist.

Bevor vom Remote abgerufen wird, wird ein Bundle von der angegebenen <uri> abgerufen und die Daten in das lokale Repository entpackt. Die Refs im Bundle werden unter dem versteckten Namespace refs/bundle/* gespeichert. Diese Option ist inkompatibel mit --depth, --shallow-since und --shallow-exclude.

Gibt das Verzeichnis an, aus dem Vorlagen kopiert werden sollen. (Siehe Abschnitt "TEMPLATE DIRECTORY" von git-init[1].)

Ermöglicht die Überschreibung des Standardzweignamens, z. B. beim Initialisieren eines neuen Repositorys.

Ermöglicht die Überschreibung des Standard-Objektformats für neue Repositories. Siehe --object-format= in git-init[1]. Sowohl die Befehlszeilenoption als auch die Umgebungsvariable GIT_DEFAULT_HASH haben Vorrang vor dieser Konfiguration.

Ermöglicht die Überschreibung des Standard-Ref-Speicherformats für neue Repositories. Siehe --ref-format= in git-init[1]. Sowohl die Befehlszeilenoption als auch die Umgebungsvariable GIT_DEFAULT_REF_FORMAT haben Vorrang vor dieser Konfiguration.

Der Name des Remote, der beim Klonen eines Repositorys erstellt wird. Standard ist origin. Er kann durch Angabe der Befehlszeilenoption --origin überschrieben werden.

Verweigert das Klonen eines Repositorys, wenn es sich um ein flaches Repository handelt; dies kann durch Angabe der Option --reject-shallow auf der Befehlszeile überschrieben werden.

Wenn ein Filter für partielle Klone angegeben ist (siehe --filter in git-rev-list[1]) und --recurse-submodules verwendet wird, wird der Filter auch auf Submodule angewendet.