Ist das zu klonende Projektarchiv lokal auf der Maschine, kann durch dieses Flag der normale Git-Transportmechanismus umgangen werden und es wird ein einfacher Kopiervorgang von HEAD und allen unter den objects und refs Verzeichnissen gelegenen Daten durchgeführt. Die Dateien unter .git/objects/ werden zum Platzsparen mittels hard link referenziert anstatt sie physikalisch zu kopieren.

Erzwingt ein physikalisches Kopieren aller Dateien im .git/objects/ Verzeichnis anstelle von Hard-Links. Dies kann erwünscht sein, wenn eine Sicherung des Repositorys erstellt werden soll.

Befindet sich das zu klonende Repository lokal auf der Maschine (anstatt Hard-Links zu verwenden), dann werden automatisch alle Objekte mittels .git/objects/info/alternates gemeinsam verwendet. Das erzeugte Repository enthält initial keine eigenen Objekte.

Wenn sich das Referenz-Repository auf dem lokalen Rechner befindet, wird automatisch .git/objects/info/alternates eingerichtet, um Objekte aus dem Referenz-Repository zu erhalten. Wenn, alternativ, ein bereits vorhandenes Repository verwendet wird, müssen weniger Objekte aus dem zu klonenden Repository kopiert werden, was die Belastung für Netzwerk und lokale Sicherung reduziert. Bei der Anwendung von --reference-if-able wird ein nicht existierendes Verzeichnis mit einer Warnung übersprungen, anstatt den Klon abzubrechen.

Objekte, die mit der Option --reference spezifiziert sind, von Referenz-Repositorys entlehnen. Dadurch wird der Netzwerktransfer reduziert und die Überführung von Objekten aus diesen Repositorys beendet, nachdem ein Klon mit den notwendigen lokalen Kopien der entlehnten Objekte erstellt wurden. Diese Option kann auch verwendet werden, wenn lokal von einem Repository geklont wird, das schon Objekte von einem anderen Repository übernimmt – das neue Repository wird wiederum Objekte vom selben Repository entlehnen. Diese Option kann verwendet werden, um die Übernahme zu stoppen.

stille Ausführung. Auf dem Standardfehlerstrom wird kein Fortschritt ausgegeben.

„Wortreich“ ausführen. Beeinflusst nicht die Fortschrittsmeldung an den Standardfehlerstrom.

Der Fortschritt wird nur standardmäßig auf der Standardfehlerausgabe angezeigt, wenn diese an ein Terminal angebunden ist, wenn nicht auch --quiet angegeben wird. Dieses Flag erzwingt die Fortschrittsanzeige auch ohne Terminalanbindung.

Übertragen Sie die angegebene Zeichenfolge an den Server, wenn Sie mit Protokollversion 2 kommunizieren. Die angegebene Zeichenfolge darf kein NUL- oder LF-Zeichen enthalten. Die Behandlung von Server-Optionen, einschließlich unbekannter, durch den Server ist serverspezifisch. Wenn mehrmals --server-option=<Option> angegeben wird, werden sie alle, wie in angegebenen Reihenfolge, an die andere Seite gesendet.

Unterdrückt das Abrufen (checkout) von HEAD, nachdem das Klonen fertig ist.

Erstellt ein bare Git-Repository. D.h. anstatt ein <Directory> zu erstellen und die Verwaltungsdateien in <Directory>/.git abzulegen, wird aus dem <Directory> selbst das $GIT_DIR. Dies impliziert offensichtlich --no-checkout, weil es nirgendwo eine Möglichkeit gibt, das Arbeitsbereich auszuchecken. Auch die Branch-Heads auf der Remote-Seite werden direkt auf die entsprechenden lokalen Branch-Heads kopiert, ohne sie auf refs/remotes/origin/ abzubilden. Wenn diese Option verwendet wird, werden weder Remote-Tracking-Branches noch die zugehörigen Konfigurationsvariablen erstellt.

Initialisiert die Sparse-Checkout-Datei so, dass das Arbeitsverzeichnis nur mit den Dateien im Stammverzeichnis (root) des Repositorys beginnt. Die Sparse-Checkout-Datei kann modifiziert werden, um das Arbeitsverzeichnis nach Bedarf zu vergrößern.

Verwendet die Funktion des partiellen Klonens und fordert den Server auf, eine Teilmenge der verfügbaren Objekte, entsprechend einem vorgegebenen Objektfilter, zu senden. Bei der Verwendung von --filter wird die mit angegebene <filter-spec> für den partiellen Klon-Filter verwendet. Zum Beispiel wird --filter=blob:none alle Blobs (Dateiinhalte) herausfiltern, bis sie von Git benötigt werden. Außerdem wird --filter=blob:limit=<size> alle BLOBs herausfiltern, die mindestens die Größe <size> haben. Weitere Details zu den Filterspezifikationen finden Sie unter der Option --filter in git-rev-list[1].

Erstellt einen Spiegel des Quell-Repositorys. Das enthält auch --bare. Im Vergleich zu --bare bildet --mirror nicht nur lokale Branches der Quelle auf lokale Branches des Ziel-Repositorys ab, sondern bildet auch alle Refs ab (einschließlich der Remote-Tracking-Branches, Notizen usw.). Es richtet eine refspec-Konfiguration ein, sodass alle diese Refs durch ein git remote update im Ziel-Repository überschrieben werden können.

Verwendet den Namen <Name> statt origin zum Tracken der Änderungen des Upstream-Repository.

Anstatt dass der neu erstellte HEAD auf den Branch zeigt, auf den der HEAD des geklonten Repositorys zeigt, verweist er stattdessen auf den Branch <Name>. In einem „non-bare“ Repository ist dies der Branch, der ausgecheckt wird. --branch kann auch Tags übernehmen und HEAD im resultierenden Repository von diesem Commit abtrennen.

Wurde diese Option angegeben und der Zugriff auf das zu klonende Repository erfolgt über SSH, so wird damit ein Nicht-Standardpfad für den Befehlsaufruf am anderen Ende angegeben.

Bestimmt das Verzeichnis, aus dem Templates ausgelesen werden sollen; (Siehe den Abschnitt "TEMPLATE DIRECTORY" in git-init[1].)

Setzt eine Konfigurations-Variable im neu angelegten Repository; die sofort nach der Initialisierung des Repositorys wirksam wird, noch bevor der Remote-Verlauf geholt oder irgendwelche Dateien ausgecheckt werden. Der Schlüssel hat das gleiche Format wie es von git-config[1] erwartet wird (z.B. core.eol=true). Wenn für den gleichen Schlüssel mehrere Werte angegeben werden, wird jeder Wert in die Konfigurationsdatei geschrieben. Auf diese Weise ist es z.B. möglich, zusätzliche Fetch-Referenzen zum Ursprungs-Remote hinzuzufügen.

Erstellt einen „flachen“ Klon mit einem auf die angegebene Anzahl von Commits gekürzten Verlauf. Das impliziert --single-branch, es sei denn, es wird --no-single-branch angegeben, um den Verlauf nahe der Spitzen aller Branches zu fetchen. Wenn Submodule gekürzt geklont werden sollen, geben Sie zusätzlich --shallow-submodules an.

Erstellt einen „flachen“, gekürzten Klon mit einem Verlauf nach dem festgelegten Zeitpunkt.

Erstellt einen flachen Klon mit einem Verlauf, der Commits ausschließt, die von einem angegebenen Remote-Branch oder Tag erreichbar sind. Diese Option kann mehrfach angegeben werden.

Klont nur die Historie, die zur Spitze eines einzelnen Branchs gehört, entweder spezifiziert durch die --branch-Option oder den primären Branch auf den der Remote-HEAD zeigt. Nachfolgende Fetches in das resultierende Repository werden nur den Remote-Tracking-Branch für den Branch aktualisieren, auf dem diese Option für das anfängliche Klonen verwendet wurde. Wenn der HEAD des Remote-Repositorys auf keinen Branch zeigte, als mit --single-branch geklont wurde, wird kein Remote-Tracking-Branch erzeugt.

Klont keine Tags und setzt in der Konfiguration remote.<Remote>.tagOpt=--no-tags, um sicherzustellen, dass zukünftige git pull und git fetch Operationen keinen Tags folgen. Nachfolgende explizite Tag-Fetches werden trotzdem funktionieren (siehe git-fetch[1]).

Initialisiert und klont nach der Erstellung des Klons Submodule auf der Basis der angegebenen Pfadspezifikation. Wenn keine Pfadspezifikation angegeben wird, werden alle Submodule initialisiert und geklont. Diese Option kann für Pfadspezifikationen, die aus mehreren Einträgen bestehen, mehrfach angegeben werden. Der resultierende Klon hat submodule.active oder "." (d.h. alle Submodule) auf die angegebene Pfadspezifikation gesetzt, wenn keine Pfadspezifikation vorhanden ist.

Alle zu klonenden Submodule werden auf eine Tiefe von 1 gekürzt.

Alle geklonten Submodule verwenden den Status der Remote-Tracking-Branch des Submoduls, um das Submodul zu aktualisieren, aber nicht den registrierten SHA-1 des Hauptprojekts. Das entspricht der Option von --remote mit dem Befehl git submodule update.

Verwendet das angegebene Verzeichnis als Speicherort für das geklonte Repository, anstatt das übliche Verzeichnis zu verwenden. Dann wird ein Dateisystem-unabhängiger, symbolischer Git-Link dorthin erstellt. Das führt dazu, dass das Git-Repository vom Arbeitsbereich getrennt werden kann.

Anzahl der gleichzeitig abgerufenen Submodule. Standardmäßig wird die Option submodule.fetchJobs verwendet.

Bezeichnet das (möglicherweise externe) Repository, das geklont werden soll. Siehe unten den Abschnitt GIT URLS für weiterführende Informationen zum Bestimmen von Repositorys.

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