Remotes: clone, push, pull, fetch

In L3 hast du lokal mit Git gearbeitet – commiten, status, log. Aber: lokal alleine ist Git ein Tagebuch. Erst durch Remotes wird es zur Team-Plattform. Diese Lektion zeigt die vier Sync-Befehle: git clone, git push, git pull, git fetch. Plus Authentifizierung (HTTPS vs. SSH) und typische Stolperfallen.

Ein Remote ist eine Kopie deines Repos auf einem Server – GitHub, GitLab, Bitbucket, eigener Server. Du kannst mit deinem lokalen Repo arbeiten und Stände synchronisieren, wann du willst. Das ist der Kern verteilter Versionsverwaltung.

1) Das Big Picture – wie Sync funktioniert

Wenn du im Team mit Git arbeitest, gibt es vier Ebenen: deine Arbeitsdateien (Working Directory), die Staging Area, dein lokales Repo, und das Remote-Repo auf dem Server. Sync-Befehle bewegen Daten zwischen diesen Ebenen:

Sync-Animator – klick durch die Befehle

Ausgangssituation: Du hast ein lokales Repo (.git) und ein Remote-Repo auf GitHub. Beide haben dieselben Commits. Klick auf die Buttons unten für die Sync-Befehle.

Diese vier Befehle sind die Brücke zwischen deinem Rechner und dem Team. git clone = neues Repo erstellen aus einem Remote. git push = lokale Commits hochschicken. git fetch = Remote-Änderungen herunterladen, aber nicht ins Working Directory übernehmen. git pull = fetch + merge in einem Schritt.

2) git clone – ein bestehendes Projekt holen

Wenn du in einem neuen Job startest oder an einem Open-Source-Projekt mitwirken willst, ist der erste Befehl meistens git clone. Er macht eine komplette Kopie des Remote-Repos auf deinen Rechner – mit Historie, Branches, allem.

git clone – das Erste, was du tust

git clone <url>vollständige Kopie

Lädt das komplette Remote-Repo herunter – alle Commits, alle Branches, alle Tags. Erstellt einen neuen Ordner mit dem Repo-Namen, initialisiert .git/, setzt den Remote automatisch auf origin und checkt den Default-Branch (meist main) aus.

git clone https://github.com/firma/projekt.git cd projekt ls # die Projekt-Dateien sind alle da git remote -v # zeigt: origin → https://...

Nach dem Clone bist du sofort arbeitsbereit. Im Gegensatz zu git init brauchst du keinen ersten Commit – du erbst die komplette Historie. Optionen: --depth 1 für einen flachen Clone (nur letzter Stand, keine alte Historie), --branch <name> für einen bestimmten Branch.

3) git push – deine Commits hochladen

Du hast lokal commitet. Aber: noch hat niemand außer dir etwas davon. Erst git push bringt deine Commits zum Remote.

git push – synchronisiert lokale Commits hoch

git push <remote> <branch>lokal → remote

Sendet alle neuen Commits des angegebenen Branches zum Remote. Standard: git push ohne Argumente sendet den aktuellen Branch an den dazugehörigen Remote (üblicherweise origin). Beim ersten Push eines neuen Branches: git push -u origin <branch> (das -u setzt das Upstream-Tracking).

git push origin main # explizit git push # Kurzform, wenn Upstream gesetzt git push -u origin feature/x # erstes Mal für neuen Branch

Wichtig: Push ist nicht rückgängig zu machen, wenn andere bereits gepullt haben. Wer Mist baut und pushed: nicht git push --force nutzen (zerstört fremde Arbeit), sondern einen Revert-Commit erstellen. Vgl. L6 für Force-Push-Diskussionen.

4) git fetch vs. git pull – der wichtige Unterschied

Die Unterscheidung wird gerne in Klausuren abgefragt. Beide holen Daten vom Remote – aber unterschiedlich:

fetch vs. pull

git fetch

Holt Remote-Änderungen.

Verändert dein Working Directory NICHT.

Aktualisiert nur die origin/main-Referenzen.

Sicher: du kannst erst schauen, dann entscheiden.

Danach: git log origin/main zeigt was neu ist.

git pull

fetch + merge in einem Schritt.

Verändert dein Working Directory.

Kann zu Merge-Konflikten führen!

Schnell, aber weniger kontrolliert.

git pull --rebase = Variante mit Rebase statt Merge.

Pull-Workflow: jeden Morgen git pull, damit du den neuesten Stand hast. Wenn du dir nicht sicher bist, ob es Konflikte geben könnte – lieber git fetch + git status + manueller Merge. git pull --rebase erzeugt sauberere Historien, weil keine Merge-Commits entstehen – Details in L6.

5) Befehls-Cheatsheet

Remote-Befehle im Überblick

git remote -v

Zeigt alle konfigurierten Remotes mit URLs. Üblicherweise nur origin.

origin https://github.com/firma/projekt.git (fetch) origin https://github.com/firma/projekt.git (push)

git remote add <name> <url>

Fügt ein weiteres Remote hinzu. Z.B. upstream für den Original-Repo eines Forks.

git remote add upstream https://github.com/original/projekt.git

git remote remove <name>

Entfernt ein Remote (nur lokal, nicht das Repo selbst).

git remote rename <alt> <neu>

Benennt ein Remote um. Selten gebraucht.

git fetch --all

Holt von allen konfigurierten Remotes Updates, nicht nur von origin.

git push --tags

Pusht auch alle Tags zum Remote. Tags werden bei normalem push nicht mitgesendet.

6) HTTPS vs. SSH – wie du dich authentifizierst

Beim Klonen siehst du zwei URL-Varianten. Beide funktionieren, mit Unterschieden:

HTTPS vs. SSH-Zugang

HTTPS

URL-Format: https://github.com/user/repo.git
Auth: Personal Access Token (PAT) oder OAuth. Wird beim Push abgefragt.
Vorteile: funktioniert hinter Firewalls, kein Schlüssel-Setup nötig.
Nachteile: bei jedem Push Auth – außer mit Credential-Manager.

SSH

URL-Format: git@github.com:user/repo.git
Auth: SSH-Schlüsselpaar (Public Key auf GitHub, Private Key auf Rechner).
Vorteile: kein wiederholtes Passwort-Tippen, sicherer.
Nachteile: einmaliges Setup (ssh-keygen + GitHub-Settings).

In der Praxis: für persönliche Geräte SSH (einmal eingerichtet, lebenslang bequem). Für temporäre Umgebungen (Sandbox, Codespaces) HTTPS mit Token. Wechseln geht jederzeit: git remote set-url origin git@github.com:user/repo.git.

7) Tracking-Branches und Upstream

Ein Konzept, das oft Verwirrung stiftet: Upstream-Tracking. Es bedeutet: dein lokaler Branch „weiß", zu welchem Remote-Branch er gehört. So funktioniert git pull ohne Argumente.

git branch -vv zeigt alle Branches mit ihren Upstream-Beziehungen.
Beim Clone wird automatisch main → origin/main getrackt.
Für neue Branches: git push -u origin feature/x setzt das Tracking beim ersten Push.
Manuell ändern: git branch --set-upstream-to=origin/main.

Wenn du eine Fehlermeldung „no upstream branch" siehst, fehlt das Tracking. Lösung: -u beim Push.

8) Häufige Probleme und Lösungen

Typische Stolperfallen beim Sync

"rejected – non-fast-forward"

Remote hat Commits, die du nicht hast. Lösung: git pull oder git pull --rebase, dann erneut pushen.

"Permission denied (publickey)"

SSH-Key nicht eingerichtet oder bei GitHub fehlend. ssh -T git@github.com testen.

"merge conflict"

Du und der Remote haben dieselben Zeilen geändert. Manuell lösen, dann commiten. Vgl. L7.

"no upstream branch"

git push -u origin <branchname> – setzt Upstream-Tracking beim ersten Push.

Push zu langsam

Vermutlich versuchst du große Binärdateien zu pushen. Lösung: .gitignore ergänzen, ggf. Git LFS.

"detached HEAD"

Du bist auf einen Tag oder alten Commit gecheckt. Lösung: git switch main oder neuen Branch erstellen.

9) Branches auf dem Remote

Wenn jemand im Team einen neuen Branch erstellt und pusht, siehst du ihn nicht automatisch. Du musst git fetch machen, dann taucht origin/<branch> auf. Mit git switch <branch> kannst du ihn dann auschecken – Git erstellt automatisch einen lokalen Branch mit Tracking zum Remote.

Befehle:

git branch -r – listet alle Remote-Branches.
git branch -a – listet lokale + Remote-Branches.
git push origin --delete feature/alt – löscht einen Branch auf dem Remote.
git fetch --prune – entfernt lokale Referenzen zu gelöschten Remote-Branches.

10) Fork-Workflow für Open Source

Bei Open-Source-Beiträgen läufst du oft so:

Fork auf GitHub: macht eine eigene Kopie des Original-Repos in deinem Account.
Clone deines Forks: git clone https://github.com/du/projekt.git.
Upstream hinzufügen: git remote add upstream https://github.com/original/projekt.git.
Branch erstellen: git switch -c feature/cool-fix.
Commiten + Pushen auf deinen Fork.
Pull Request auf GitHub erstellen – vom Branch deines Forks gegen upstream/main.
Regelmäßig git fetch upstream, um synchron zu bleiben.

Mehr zu Pull Requests in L9.

Zusammenfassung

Remote = Server-Kopie des Repos (GitHub/GitLab), Standardname origin. git clone <url>: komplette Repo-Kopie holen. git push: lokale Commits hochladen. git fetch: Remote-Änderungen holen ohne Merge. git pull: fetch + merge in einem. Authentifizierung: HTTPS (Token) oder SSH (Schlüssel). Upstream-Tracking: git push -u origin <branch> beim ersten Push. Nächste Lektion: Branching.