git clone: Repository von GitHub und anderen Servern klonen

Der Befehl git clone erstellt eine vollständige lokale Kopie eines Remote-Repositorys: Dateien, die gesamte Commit-Historie, Branches und Tags. Das ist der übliche Weg, mit einem Projekt zu beginnen, das bereits auf GitHub, GitLab oder einem Firmenserver liegt. Anders als ein heruntergeladenes ZIP-Archiv ist ein Klon ein vollwertiges Repository, in dem Sie committen und Änderungen zurückschicken können.

git clone: Grundlagen

Kopieren Sie die Adresse des Repositorys (auf GitHub über den grünen Button „Code“) und führen Sie aus:

git clone https://github.com/username/project.git

Cloning into 'project'...
remote: Enumerating objects: 1532, done.
remote: Counting objects: 100% (1532/1532), done.
remote: Compressing objects: 100% (812/812), done.
Receiving objects: 100% (1532/1532), 2.41 MiB | 6.10 MiB/s, done.
Resolving deltas: 100% (701/701), done.

Git legt im aktuellen Verzeichnis den Ordner project an (der Name stammt aus der Adresse ohne .git). Wechseln Sie anschließend hinein:

cd project
git status

Was git clone im Hintergrund macht

Klonen ist mehr als Dateien herunterladen. Wer diese Schritte kennt, versteht, warum nach dem Klonen alles „einfach funktioniert“ und woher die Branches mit dem Präfix origin/ kommen. Der Befehl geht so vor:

1. erstellt einen Ordner und führt darin das Gegenstück zu git init aus;
2. fügt ein Remote namens origin hinzu, das auf die Quelladresse zeigt;
3. lädt alle Objekte und Referenzen herunter — entspricht git fetch;
4. legt die Remote-Branches origin/main, origin/develop usw. an;
5. erstellt den lokalen Standard-Branch (meist main), verknüpft ihn mit origin/main und checkt die Dateien aus.

Deshalb müssen Sie nach dem Klonen kein git remote manuell einrichten — git push und git pull funktionieren sofort.

git remote -v
origin  https://github.com/username/project.git (fetch)
origin  https://github.com/username/project.git (push)

Klonen per HTTPS oder SSH

Um fremde öffentliche Projekte zu lesen, reicht HTTPS. Für eigene Repositorys, in die Sie regelmäßig pushen, ist SSH bequemer:

git clone git@github.com:username/project.git

Haben Sie bereits per HTTPS geklont und wollen zu SSH wechseln, müssen Sie nicht neu herunterladen:

git remote set-url origin git@github.com:username/project.git

In einen bestimmten Ordner klonen

Das zweite Argument ist der Name oder Pfad des Zielverzeichnisses:

# In einen Ordner mit anderem Namen
git clone https://github.com/username/project.git my-copy

# In den aktuellen Ordner (er muss leer sein)
git clone https://github.com/username/project.git .

Existiert der Zielordner und ist nicht leer, verweigert Git: fatal: destination path 'project' already exists and is not an empty directory.

Einen bestimmten Branch klonen

Standardmäßig landen Sie nach dem Klonen auf dem Standard-Branch des Remote-Repositorys. Um direkt auf einem anderen zu starten, verwenden Sie -b (--branch):

git clone -b develop https://github.com/username/project.git

Beachten Sie: Dabei werden trotzdem alle Branches heruntergeladen, Sie stehen nur auf develop. Brauchen Sie ausschließlich diesen einen Branch, ergänzen Sie --single-branch:

git clone -b develop --single-branch https://github.com/username/project.git

Das Flag -b akzeptiert auch einen Tag-Namen — dann erhalten Sie den Projektstand zum Zeitpunkt des Releases (im Modus detached HEAD):

git clone -b v2.1.0 --depth 1 https://github.com/username/project.git

Wo sind die anderen Branches nach dem Klonen?

Einsteiger wundern sich: git branch zeigt nur main. Die übrigen Branches wurden als Remote-Branches geladen; Sie sehen sie so:

git branch -a

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/develop
  remotes/origin/feature/login

Um in einem davon zu arbeiten, wechseln Sie einfach über den Kurznamen — Git erstellt selbst einen lokalen Branch, der dem Remote-Branch folgt:

git switch develop

Flacher Klon: --depth für große Repositorys

Bei alten Projekten kann die Historie Gigabytes groß sein. Brauchen Sie nur den aktuellen Code — etwa in der CI oder um das Projekt einfach zu bauen —, laden Sie nur die letzten Commits:

git clone --depth 1 https://github.com/username/big-project.git

Das Flag --depth impliziert --single-branch, es kommen also nur der Standard-Branch und ein Commit. Brauchen Sie später die vollständige Historie, laden Sie sie nach:

git fetch --unshallow

Sie können auch eine andere Tiefe angeben, etwa --depth 50, oder die Historie per Datum begrenzen: --shallow-since=2025-01-01. Für aktive Entwicklung ist ein flacher Klon unpraktisch: git log, git blame und die Suche in der Historie bleiben unvollständig.

Partieller Klon: --filter

Eine Alternative für riesige Monorepos: die Commit-Historie laden, Dateiinhalte aber erst bei Bedarf nachholen:

git clone --filter=blob:none https://github.com/username/monorepo.git

So behalten Sie die vollständige Historie für log und Branch-Wechsel, sparen aber Bandbreite und Speicher. Der Server muss das unterstützen; GitHub und GitLab tun es.

Spiegel-Klon und Umzug eines Repositorys

Ein normaler Klon übernimmt Branches als Remote-Branches und kopiert keine internen Server-Referenzen. Um ein Projekt zu einem anderen Hoster umzuziehen oder eine exakte Sicherungskopie anzulegen, nutzt man --mirror:

git clone --mirror https://github.com/username/project.git
cd project.git
git push --mirror git@gitlab.com:username/project.git

Ein Spiegel ist ein Bare-Repository ohne Arbeitsdateien, in dem alle Branches und Tags als lokale gespeichert sind. git push --mirror überträgt sie vollständig auf den neuen Server, die Historie wandert verlustfrei mit. Issues, Pull Requests und Hoster-Einstellungen werden so allerdings nicht übertragen — das sind Daten des Dienstes, nicht von Git.

Das ähnliche Flag --bare erstellt ebenfalls ein Repository ohne Arbeitsverzeichnis, kopiert aber nur Branches und Tags. Es eignet sich, um aus einem bestehenden Projekt ein zentrales Repository auf dem eigenen Server aufzusetzen.

Klonen mit Submodulen

Nutzt das Projekt Git-Submodule, sind deren Ordner standardmäßig leer. Um alles auf einmal zu laden:

git clone --recurse-submodules https://github.com/username/project.git

Haben Sie schon ohne das Flag geklont, holen Sie die Submodule nach:

git submodule update --init --recursive

git clone, Fork und ZIP-Download

Fork und Clone konkurrieren nicht: Bei Open Source forkt man zuerst auf der Website, klont dann den eigenen Fork und fügt das Original als zweites Remote hinzu:

git clone git@github.com:me/project.git
cd project
git remote add upstream https://github.com/author/project.git
git fetch upstream

Häufige Fehler bei git clone

„Repository not found“

Tippfehler in der Adresse, oder das Repository ist privat und Sie haben keinen Zugriff. GitHub antwortet bei privaten Repositorys absichtlich mit „not found“ statt „Zugriff verweigert“. Prüfen Sie die Adresse und ob Sie mit dem richtigen Konto angemeldet sind.

„Permission denied (publickey)“

Klonen per SSH, aber der Schlüssel ist nicht eingerichtet. Prüfen Sie ssh -T git@github.com, fügen Sie den öffentlichen Schlüssel in den Kontoeinstellungen hinzu oder klonen Sie vorübergehend per HTTPS.

„Authentication failed“ bei HTTPS

Sie haben Ihr Kontopasswort eingegeben. GitHub verlangt für Git-Operationen über HTTPS schon lange ein Personal Access Token statt des Passworts. Hat Git falsche Zugangsdaten gespeichert, löschen Sie sie in der Anmeldeinformationsverwaltung des Systems.

Abbruch bei großen Repositorys

Fehler wie early EOF oder RPC failed hängen oft mit instabilem Netz und der Größe zusammen. Abhilfe schafft ein flacher Klon mit --depth 1 und anschließendem git fetch --unshallow oder ein Klon per SSH.

Probleme mit Zeilenenden unter Windows

Nach dem Klonen sind alle Dateien „geändert“ — so äußert sich die CRLF/LF-Konvertierung. Setzen Sie unter Windows git config --global core.autocrlf true (unter Linux und macOS input) und legen Sie die Regeln besser in der .gitattributes des Projekts fest.

Was direkt nach dem Klonen zu tun ist

Der Klon ist fertig, doch bevor Sie Code ändern, lohnen sich ein paar Minuten Vorbereitung. Das erspart typische Probleme schon am ersten Tag mit einem fremden Projekt.

1. README und CONTRIBUTING lesen. Dort steht meist, wie man Abhängigkeiten installiert, Tests startet und wie Branches im Projekt benannt werden.
2. Branch und Zustand prüfen. git status und git log --oneline -5 zeigen, wo Sie stehen und was zuletzt geändert wurde.
3. Eigenen Branch erstellen. Arbeiten Sie nicht direkt in main: git switch -c feature/my-task.
4. Commit-Autor prüfen. Haben Sie mehrere Konten auf dem Rechner (privat und beruflich), setzen Sie die E-Mail für dieses Repository ohne --global: git config user.email "you@company.com".
5. Abhängigkeiten installieren. Ordner wie node_modules oder venv gehören nicht ins Repository, sie werden lokal erzeugt: npm install, pip install -r requirements.txt usw.

Den Klon aktuell halten

Geklont wird nur einmal. Danach holen Sie neue Commits von Kollegen aus demselben origin:

# Ansehen, was auf dem Server neu ist, ohne etwas zu ändern
git fetch
git log --oneline main..origin/main

# Änderungen in den aktuellen Branch übernehmen
git pull

Die Gewohnheit, erst git fetch auszuführen und anzusehen, was angekommen ist, bewahrt vor unerwarteten Konflikten. Ein Projekt „zum Aktualisieren“ erneut zu klonen ist unnötig — dabei gehen lokale Branches und nicht committete Arbeit verloren.

Spickzettel für git clone

Fazit

git clone lädt ein Repository vollständig herunter und richtet über origin sofort die Verbindung zum Server ein — danach können Sie ohne weitere Konfiguration committen, pushen und pullen. Für eigene Projekte nutzen Sie SSH, für große --depth oder --filter, für einen bestimmten Branch -b. Die Arbeit mit Remote-Repositorys, push, pull und fetch wird im Git-Kurs praktisch behandelt.