Von Gast (nicht überprüft) , 29 April 2026

Einführung

git clone kopiert ein Remote-Repository auf Ihre Maschine. Es erstellt ein neues Verzeichnis, initialisiert .git darin, lädt alle Objekte und Refs herunter, richtet einen Remote namens origin ein und checkt den Standard-Branch aus. Nach dem Klonen haben Sie ein vollständiges, unabhängiges Repository.

Grundlegender Klon

git clone https://github.com/torvalds/linux.git
cd linux
git remote -v
# origin  https://github.com/torvalds/linux.git (fetch)
# origin  https://github.com/torvalds/linux.git (push)

Verzeichnisnamen wählen

Standardmäßig verwendet Git die letzte Pfadkomponente. Überschreiben Sie sie:

git clone https://github.com/example/widget.git my-widget

Ein Protokoll wählen

  • HTTPS: am einfachsten, funktioniert durch Firewalls, benötigt oft einen Credential-Helper oder ein Token.
  • SSH: bequem mit Schlüsselauthentifizierung, schnell für Power-User.
  • git://: anonym, unauthentifiziert, meist historisch.
  • file:// oder lokaler Pfad: aus einem anderen Verzeichnis klonen.
git clone [email protected]:example/widget.git
git clone /srv/git/widget.git
git clone file:///srv/git/widget.git

Nützliche Optionen

git clone --depth 1 <url>            # shallow: nur die Spitze
git clone --branch v1.2.3 <url>     # einen bestimmten Branch oder Tag auschecken
git clone --single-branch <url>     # nur einen Branch holen
git clone --bare <url>              # Bare-Klon, kein Working Tree
git clone --recurse-submodules <url>

Shallow-Clones sparen Bandbreite für CI; konvertieren Sie später mit git fetch --unshallow.

Was clone Schritt für Schritt tut

  1. Erstellt das Zielverzeichnis.
  2. Führt darin git init aus.
  3. Fügt origin als Remote hinzu.
  4. Führt git fetch origin aus.
  5. Richtet Tracking für den Standard-Branch ein.
  6. Führt git checkout für diesen Branch aus.

Sparse- und Partial-Clones für riesige Repositories

Repositories, die Gigabyte umfassen (Betriebssysteme, Monorepos), sind schmerzhaft, vollständig zu klonen. Zwei sich ergänzende Funktionen helfen:

git clone --filter=blob:none --no-checkout <url> repo
cd repo
git sparse-checkout init --cone
git sparse-checkout set src/myteam
git checkout main

--filter=blob:none verschiebt Blob-Downloads auf später, während sparse-checkout nur die von Ihnen aufgelisteten Verzeichnisse befüllt. Zusammen erlauben sie es Ihnen, an einem kleinen Ausschnitt eines massiven Repositories mit proportionalen Festplatten- und Bandbreitenkosten zu arbeiten.

Klon-Zeit-Hooks

Manche Projekte liefern Setup-Schritte, die beim Klonen ausgeführt werden sollten (Pre-Commit-Hooks installieren, LFS-Objekte holen, Submodules initialisieren). Git führt beim Klonen keine Hooks aus, aber Sie können sie verketten:

git clone --recurse-submodules <url> repo
cd repo
git lfs install
pre-commit install

Für neue Mitwirkende dokumentieren Sie diese Sequenz in CONTRIBUTING.md oder umhüllen Sie sie mit einem scripts/bootstrap-Skript. Schlaue Projekte machen ihr make setup-Target idempotent, sodass das erneute Ausführen nach einem veralteten Klon sicher ist.

Häufige Fehler

Klonen in ein nicht-leeres Verzeichnis: Git verweigert dies, es sei denn, Sie übergeben ein explizit leeres Ziel. Klonen riesiger Repositories ohne --depth über langsame Verbindungen und dann auf halbem Weg aufgeben. Klonen über HTTPS auf einen Server, der SSO erfordert, und dann nicht pushen können, weil Ihrem Token der richtige Scope fehlt. Testen Sie nach dem ersten Commit immer mit git push --dry-run. Schließlich: Klonen in ~/Desktop oder einen anderen Sync-Ordner (Dropbox, iCloud, OneDrive) führt zu Korruption, wenn der Sync-Client mitten im Schreiben von .git/index agiert. Halten Sie Arbeitsklone auf einfachem lokalem Speicher.