Einführung

Git ist ein verteiltes Versionskontrollsystem: Jeder Klon ist ein vollständiges Repository mit seiner eigenen vollständigen Historie – keine bloße Arbeitskopie, die von einem zentralen Server ausgecheckt wurde. Deshalb dreht sich die Zusammenarbeit in Git im Wesentlichen um Synchronisierung: das Austauschen ganzer Branches zwischen Repositories, anstatt einzelne Änderungssätze weiterzugeben.

Diese Seite stellt die vier Befehle vor, die Commits zwischen deinem lokalen Repository und entfernten Repositories bewegen: git remote, git fetch, git push und git pull. Jeder Befehl wird auf einer eigenen Seite ausführlich behandelt, aber zu verstehen, wie sie zusammenspielen, macht die tägliche Zusammenarbeit vorhersehbar.

Das mentale Modell: lokal vs. remote

Bevor wir zu den einzelnen Befehlen kommen, hilft es, ein einfaches Bild im Kopf zu behalten. Beim Synchronisieren sind drei Dinge beteiligt:

• Dein lokales Repository — die Branches, in die du commitest, z. B. main.
• Ein Remote — ein benannter Zeiger (wie origin), der auf die URL eines anderen Repositories verweist.
• Remote-Tracking-Branches — schreibgeschützte lokale Kopien der Branches des Remotes, benannt nach dem Muster origin/main. Sie zeichnen auf, wo der Remote war, als du zuletzt mit ihm kommuniziert hast.

Die Richtung des Datenflusses zeigt dir, welchen Befehl du verwenden musst:

• git fetch und git pull holen Commits herunter vom Remote.
• git push sendet Commits hinauf zum Remote.
• git remote verwaltet die Verbindungen selbst.

git remote

Der Befehl git remote dient zum Erstellen, Anzeigen und Entfernen von Verbindungen zu anderen Repositories. Standardmäßig listet er alle zuvor gespeicherten Remote-Verbindungen auf.

Wenn du ein Repository klonst, erstellt Git automatisch einen Remote namens origin, der auf die Quell-URL zurückverweist. Daher musst du für eigene Projekte selten manuell einen Remote hinzufügen. Weitere Remotes fügst du hinzu, wenn du über Forks hinweg zusammenarbeitest – zum Beispiel, wenn du upstream auf das ursprüngliche Projekt zeigen lässt, das du geforkt hast.

# List configured remotes
git remote
# origin

# Show their fetch/push URLs
git remote -v
# origin  https://github.com/user/repo.git (fetch)
# origin  https://github.com/user/repo.git (push)

# Add a second remote
git remote add upstream https://github.com/original/repo.git

git fetch

Der Befehl git fetch lädt Commits, Dateien und Referenzen von einem Remote-Repository in dein lokales Repository herunter und aktualisiert dabei deine Remote-Tracking-Branches (wie origin/main). So kannst du sehen, woran andere Teammitglieder gearbeitet haben, ohne deinen eigenen Arbeitsbranch zu verändern.

Sowohl git fetch als auch git pull laden Inhalte vom Remote herunter, aber git fetch ist die sichere, nicht-destruktive Option: Es aktualisiert nur die Remote-Tracking-Branches und verändert niemals deine Arbeitsdateien. Nichts wird gemergt, bis du es explizit verlangst.

# Download new commits from origin (does not change your working branch)
git fetch origin

# Review what arrived before integrating it
git log main..origin/main

# Integrate it yourself when ready
git merge origin/main

Dieses Muster „fetch, dann überprüfen, dann mergen" ist der Grund, warum viele Teams git fetch gegenüber git pull bevorzugen: Du kannst eingehende Änderungen prüfen, bevor sie auf dem Branch landen, den du gerade bearbeitest.

git push

Der Befehl git push lädt den Inhalt deines lokalen Repositories in ein Remote-Repository hoch. Während git fetch Commits in deine lokalen Remote-Tracking-Branches importiert, exportiert git push deine lokalen Commits in die entsprechenden Branches auf dem Remote, sodass der Rest des Teams sie sehen kann.

# Push the current branch's commits to origin
git push origin main

# First push of a new branch: set up tracking with -u
git push -u origin feature-login

Ein Push gelingt nur, wenn er den Remote-Branch vorwärts bewegen kann, ohne Commits zu verlieren (ein Fast-Forward). Hat jemand anderes in der Zwischenzeit gepusht, lehnt Git den Push ab und fordert dich auf, zuerst dessen Arbeit zu integrieren – üblicherweise mit git pull oder git fetch und anschließendem Mergen. Vermeide --force auf gemeinsam genutzten Branches: Es kann die Commits von Teammitgliedern überschreiben.

git pull

Der Befehl git pull ist im Wesentlichen git fetch gefolgt von einem Integrationsschritt – alles in einem einzigen Befehl. Er lädt neue Inhalte vom Remote herunter und integriert sie sofort in deinen aktuellen Branch.

Standardmäßig kombiniert git pull das git fetch mit git merge und erzeugt einen Merge-Commit, wenn die Historien auseinandergegangen sind. Du kannst es so konfigurieren, dass stattdessen git rebase verwendet wird (git pull --rebase), was deine lokalen Commits auf die heruntergeladenen aufpfropft und so eine lineare Historie ergibt.

# Fetch from origin and merge into the current branch
git pull origin main

# Fetch and rebase your local commits on top instead
git pull --rebase origin main

Wann welchen Befehl verwenden

Eine schnelle Entscheidungshilfe für den Alltag:

• Arbeitstag beginnt? Führe git pull aus (oder git fetch + überprüfen + mergen), um die neuesten Änderungen zu holen.
• Sehen, was sich geändert hat, ohne die eigene Arbeit zu stören? Nutze git fetch, dann git log oder git diff gegen origin/<branch>.
• Einen Arbeitsabschnitt abgeschlossen? Führe git push aus, um ihn zu teilen.
• Push wurde abgelehnt? Der Remote hat Commits, die du noch nicht hast. Pull (oder fetch und merge/rebase), löse eventuelle Konflikte, dann push erneut.

Sieh dir von hier aus die eigenen Seiten zu jedem Befehl an und lies das Kapitel zu Git-Workflows, um zu erfahren, wie Teams diese Befehle zu einem wiederholbaren Prozess kombinieren.

Übungen