Git-Remote: Der komplette Guide mit Beispielen

Git ist ein verbreitetes Versionskontrollsystem (VCS) in der Softwareentwicklung, mit dem Änderungen an Dateien im Zeitverlauf nachverfolgt werden. Es erleichtert die Zusammenarbeit, weil mehrere Entwicklerinnen und Entwickler parallel arbeiten können, ohne sich gegenseitig zu überschreiben. Da alle eine vollständige lokale Kopie der Projekt-Historie haben, kann jede Person unabhängig und offline arbeiten und ihre Änderungen bei Bedarf sicher zusammenführen.

Remote-Repository oder kurz Remote ist die gehostete Version deines Git-Projekts in der Cloud, zum Beispiel bei GitHub oder BitBucket.

In diesem Artikel schauen wir uns Git-Remotes im Detail an. Wenn du neu bei Git bist, wirf am besten vorher einen Blick in unser Git-Tutorial für Einsteiger. 

Was ist ein Git-Remote?

Ein Git-Remote bietet einen zentralen Ort, an dem ein Repository gespeichert, geteilt und von anderen abgerufen werden kann. Nutzerinnen und Nutzer können ihre lokalen Änderungen zum Remote pushen und Updates von Teammitgliedern vom Remote pullen. Remotes eignen sich außerdem als Code-Backup und für Deployments in Produktionsumgebungen.

Ein lokales Repository liegt auf deinem Rechner, sodass du Code schreiben, Commits erstellen und Änderungen lokal testen kannst. Ein Remote-Repository liegt online und dient zum Teilen von Code, zur Zusammenarbeit und zur Sicherung deiner Arbeit. In diesem Artikel zeigen wir, wie du Änderungen zwischen lokalem und Remote-Repo mit Git-Befehlen synchronisierst.

Git-Workflow

Ein typischer Git-Workflow beginnt damit, ein Remote-Repository auf deinen Rechner zu „klonen“. Nach dem Klonen erstellst du meistens einen neuen Branch für ein Feature oder einen Fix, nimmst Änderungen vor und committest diese lokal. 

Sobald deine Arbeit bereit ist, „pushst“ du den Branch zum Remote und eröffnest einen Pull-Request zur Review. Nach der Freigabe mergst du die Änderungen in den Main-Branch. 

Während des gesamten Prozesses „pullst“ du regelmäßig Updates, damit dein lokales Repository mit dem Remote synchron bleibt.

Ein typischer Git-Workflow (Bild aus dem Introduction to Git Course)

Schauen wir uns diesen Ablauf genauer an.

Ein Repo klonen

Angenommen, du möchtest eine Kopie eines Remote-Repositories erstellen – dieser Vorgang heißt „Klonen“. Mit einer lokalen Kopie kannst du den Code ändern und neue Features testen.

Stelle sicher, dass Git installiert ist, öffne dann ein Terminal und nutze den Befehl: git clone <URL>.

Um zum Beispiel ein Projekt namens „project“ von einer GitHub-Seite mit dem Benutzernamen „datacamp“ zu klonen, verwendest du

git clone https://github.com/datacamp/project.gitBereitgestellt von

Standard-Remote: „origin“

Wenn du ein Repository klonst, legt Git ein Standard-Remote namens origin an. Das Label origin fungiert als Alias für die URL des Repositories, von dem du geklont hast.

In typischen Git-Workflows nimmt Git bei Befehlen wie git push oder git pull an, dass du dich auf origin beziehst, sofern du kein anderes Remote angibst. Das vereinfacht die Synchronisation zwischen deiner lokalen Kopie und dem geteilten Repository. Weiter unten gehen wir auf Push und Pull noch genauer ein.

Git-Remotes verwalten

Typische Aufgaben bei der Remote-Verwaltung sind das Anzeigen vorhandener Remotes mit git remote und das Hinzufügen eines neuen Remotes mit git remote add.

Vorhandene Remotes anzeigen

Um vorhandene Remotes anzuzeigen, verwende den Befehl git remote. 

git remote
>> originBereitgestellt von

In unserem Beispiel wird der Remote-Alias origin aufgelistet, aber die URL wird nicht angezeigt. Wenn du die zugehörigen URLs sehen möchtest, nutze die Option -v.

git remote -v
>> origin	https://github.com/datacamp/project.git (fetch)
>> origin	https://github.com/datacamp/project.git (push)Bereitgestellt von

Ein neues Remote hinzufügen

Du kannst dein lokales Repository mit einem weiteren Remote verbinden. Wenn du zum Beispiel ein Projekt geforkt hast, möchtest du neben Änderungen an main auch die Änderungen im ursprünglichen Repository verfolgen. Oder du willst deinen Code auf mehrere Plattformen wie GitHub und GitLab pushen.

Um ein neues Remote hinzuzufügen, nutze git remote add <name> <URL>. Fügen wir ein neues Remote namens new_remote hinzu.

git remote add new_remote https://github.com/datacamp/projectBereitgestellt von

Die Benennung des Remotes ist praktisch, damit du die URL beim Arbeiten nicht immer wieder eintippen musst.

Remotes umbenennen und entfernen

Ein Remote umzubenennen ist unkompliziert. Verwende den Befehl git remote rename <alter-name> <neuer-name>. Zum Beispiel:

git remote rename new_remote original_remoteBereitgestellt von

Um zu prüfen, ob das Remote umbenannt wurde, liste die Remotes mit git remote auf.

Um ein Remote zu entfernen, nutze git remote remove <name>. In unserem Beispiel:

git remote remove new_remoteBereitgestellt von

Liste nun die Remotes auf, um es zu verifizieren.

git remote
>> originBereitgestellt von

Wir sehen, dass origin das einzige Remote ist.

Mit Remote-Branches arbeiten

Ein Branch in Git ist ein eigener Entwicklungszweig neben main. So kannst du Änderungen unabhängig von der Hauptversion deines Projekts umsetzen. Ist deine Arbeit fertig und geprüft, mergst du den Branch zurück in das Hauptprojekt.

Remote-Branches auflisten

Um Remote-Branches aufzulisten, verwenden wir git branch -r.

git branch -r
>> origin/HEAD -> origin/main
>> origin/mainBereitgestellt von

Interpretieren wir die Ausgabe: Die Zeile origin/main zeigt, dass es auf dem Remote origin einen Remote-Branch namens main gibt. Die Zeile origin/HEAD -> origin/main zeigt, dass der Standard-Branch auf dem Remote origin/main ist. Insgesamt sagt dir die Ausgabe also, dass main der Standard-Branch auf dem Remote origin ist und derzeit als einziger Remote-Branch gelistet wird.

Einen Remote-Branch tracken

Oft willst du einen lokalen Branch mit einem Remote-Branch verknüpfen, um deinen Code synchron zu halten. Wenn ein lokaler Branch einen Remote-Branch „tracked“, kannst du pullen und pushen, ohne jedes Mal Remote- und Branchnamen anzugeben. 

Git verfolgt außerdem, wie viele Commits dein lokaler Branch dem Remote voraus oder hinterher ist – das erleichtert das Änderungsmanagement.

Der Befehl git checkout --track origin/<branch-name> erstellt einen neuen lokalen Branch, der den angegebenen Remote-Branch trackt. Er legt lokal einen Branch mit demselben Namen wie <branch-name> an und verknüpft ihn mit der Remote-Version. Künftige git pull- und git push-Befehle interagieren damit automatisch mit dem richtigen Remote-Branch. Mehr zu Git Push und Pull findest du in unserem Tutorial. 

Von Remotes fetchen und pullen

Damit dein lokaler Branch mit den Änderungen anderer aktuell bleibt, musst du Inhalte in deinen lokalen Branch holen. „Pullen“ bedeutet, die neuesten Änderungen vom entsprechenden Branch auf dem Remote herunterzuladen und in deine lokale Version dieses Branches zu mergen. So arbeitest du stets mit dem aktuellsten Code.

Angenommen, wir wollen alle Branches vom Remote origin holen. Das geht mit git fetch origin. Möchtest du nur einen bestimmten Branch wie main fetchen, gib ihn an, z. B. git fetch origin main.

Nach dem Fetchen musst du die Inhalte noch synchronisieren, indem du die geholten Änderungen in deinen aktuellen lokalen Branch mergst. Führe dazu git merge origin/<branch-name> aus und ersetze <branch-name> durch den gefetchten Branch. Um z. B. Änderungen vom Remote-Branch main zu mergen, verwendest du git merge origin/main.

Weil Fetch und Merge oft direkt hintereinander erfolgen, bietet Git einen kombinierten Befehl: git pull. Um z. B. Änderungen vom Branch main des Remotes origin zu holen und zu mergen, nutzt du git pull origin main.

Wann solltest du fetch und merge nutzen und wann pull? Der zweistufige Prozess aus fetch und merge gibt dir mehr Kontrolle über das Update. Mit Fetch siehst du zuerst, was sich auf dem Remote geändert hat, bevor du es in deinen lokalen Branch mergst. Das ist hilfreich, wenn du Updates prüfen, Unterschiede vergleichen oder potenzielle Konflikte sorgfältig behandeln willst. 

Nutze pull, wenn du sicher bist, dass die Remote-Änderungen sofort gefahrlos gemergt werden können und du deinen Branch schnell aktualisieren willst. Das ist bequem und kombiniert beide Schritte, bietet aber weniger Transparenz vor dem Merge.

In ein Remote-Repository pushen

„Pushen“ bedeutet, dass du deine lokalen Änderungen in den entsprechenden Branch des Remote-Repositories hochlädst. So wird das Remote mit deiner aktuellen Arbeit aktualisiert, andere können sie sehen, pullen oder darauf aufbauen. Pushing teilt deine Beiträge und hält das Remote-Repository für alle im Projekt aktuell.

Das Hochladen lokaler Änderungen ins Remote erfolgt in drei Schritten.

1. Nutze git add, um die gewünschten Dateien zu stagen. Um alle Änderungen hinzuzufügen, verwende

git addBereitgestellt von

Um eine bestimmte Datei hinzuzufügen, gib ihren Dateinamen an.

git add <filename>Bereitgestellt von

2. Committe deine Änderungen. Füge eine Nachricht hinzu, die beschreibt, was du gemacht hast.

git commit -m “Your commit message here”Bereitgestellt von

3. Pushe ins Remote.

git push origin branch-nameBereitgestellt von

Praktische Beispiele

Schauen wir uns einige Praxisbeispiele an: ein Repo klonen und mit mehreren Remotes zusammenarbeiten.

Ein Repository klonen

So klonst du ein Repo Schritt für Schritt.

1. Repository-URL besorgen. Kopiere die URL des Repositories, das du klonen willst. Die URL bekommst du bei deinem Cloud-Anbieter wie GitHub oder BitBucket.
2. Verzeichnis wählen. Wechsle in den Ordner auf deinem Rechner, in den das Repo kopiert werden soll.
3. Repository klonen. Führe git clone <URL> aus. Zum Beispiel git clone https://github.com/datacamp/project.Dadurch entsteht ein neuer Ordner namens project mit dem Inhalt des Repos.
4. Konfigurierte Remotes auflisten. Prüfe nach dem Klonen die Remotes mit git remote.In unserem Beispiel siehst du origin, den Standardnamen, den Git dem Remote gibt, von dem du geklont hast, inklusive der URL.

Zusammenarbeit mit mehreren Remotes

Wenn du zu einem Open-Source-Projekt beiträgst oder über eine persönliche Kopie (Fork) mitarbeitest, arbeitest du oft mit zwei Remotes: origin, das ist dein Fork des Repos, und upstream, das ist das Repo, von dem du geforkt hast. In der Regel hast du Schreibrechte auf origin, aber nicht auf upstream.

Beachte dabei einige Best Practices für den Umgang mit mehreren Remotes.

1. Das Remote upstream hinzufügen. Nachdem du deinen Fork geklont hast, behalte das Originalrepo als upstream im Blick: git remote add upstream <URL>.
2. Deinen Fork aktuell halten. Hole regelmäßig Änderungen aus dem Upstream-Repo mit git fetch upstream und merge oder rebase diese in deinen lokalen Branch.
3. Nicht in das Repo upstream pushen. Üblicherweise hast du keine (und brauchst auch keine) Push-Rechte auf das upstream-Repo. Pushe alle Änderungen nach origin und eröffne Pull-Requests von dort.
4. Aussagekräftige Branchnamen verwenden. Halte deine lokalen Branches organisiert. Benenne sie idealerweise nach dem Feature oder Issue, an dem du arbeitest.
5. Remotes prüfen. Nutze git remote -v, um deine Remote-Konfiguration zu überprüfen und sicherzustellen, dass die URLs für origin und upstream korrekt sind.
6. Vor dem Arbeiten synchronisieren. Bevor du neue Arbeit startest, ziehe immer die neuesten Änderungen von upstream in deinen Main-Branch, um aktuell zu bleiben und spätere Konflikte zu vermeiden.

Best Practices und Tipps für Git-Remotes

Hier sind einige Best Practices, die du beim Einsatz von Git-Remotes befolgen solltest: 

Remotes aktuell halten

Regelmäßiges Fetchen sorgt dafür, dass deine lokale Kopie des Repositories auf dem Stand des Remotes bleibt. Mit git fetch lädst du neue Änderungen vom Remote herunter, ohne deinen aktuellen Branch zu verändern. 

So behältst du im Blick, was Kolleginnen und Kollegen gepusht haben, kannst Änderungen vergleichen und dich auf notwendige Updates oder Merges vorbereiten. Regelmäßiges Fetchen reduziert Konflikte und hält die Zusammenarbeit reibungslos.

Mit der Zeit werden auf dem Remote gelöschte Branches lokal oft noch als Remote-Tracking-Branches angezeigt. Diese veralteten Referenzen nennt man „stale“ Remote-Tracking-Branches. 

Zum Aufräumen führst du git remote prune origin aus. Dadurch werden Remote-Tracking-Branches entfernt, die auf dem Remote origin nicht mehr existieren. 

Regelmäßiges Aufräumen hält dein lokales Repository übersichtlich, erleichtert das Finden relevanter Branches und verhindert, dass du auf veraltete Arbeit verweist.

Konflikte mit Remotes lösen

Remote-Konflikte können knifflig sein. Am besten vermeidest du sie, indem nicht mehrere Personen gleichzeitig an denselben Codestellen arbeiten. Das ist jedoch nicht immer möglich. 

Trotz bester Planung passieren Konflikte. Wenn es dazu kommt, hilft dieser Fahrplan:

1. Nutze git status, um zu sehen, welche Konflikte deine Aufmerksamkeit benötigen.
2. Öffne die betroffenen Dateien und löse die Konflikte durch Bearbeitung.
3. Nutze ein Merge-Tool. Tools wie VS Code oder git mergetool zeigen dir Gegenüberstellungen und lassen dich auswählen, welche Version übernommen wird.
4. Kommuniziere mit dem Team. Ist der Konflikt unklar, stimme dich vor der Auflösung mit deinen Kolleginnen und Kollegen ab. Verstehe, welche Zeilen bleiben und welche entfernt werden sollen.
5. Teste deinen Code nach der Auflösung, damit nichts kaputt ist und alles wie erwartet funktioniert.
6. Committe deine Änderungen. Stage nach der Auflösung alle Dateien und erstelle einen Commit, um den Merge abzuschließen.

Rebase

Mit git pull --rebase senkst du die Wahrscheinlichkeit komplexer Merge-Konflikte, indem deine Änderungen auf die neuesten Remote-Commits „oben drauf“ angewendet werden.

Bei git pull --rebase holt Git zuerst die neuesten Änderungen vom Remote und spielt danach deine lokalen Commits so ein, als wären sie anschließend entstanden.

Das sorgt für eine sauberere, lineare Commit-Historie und reduziert die Gefahr unübersichtlicher Merge-Konflikte.

Anstatt einen Merge-Commit zu erzeugen, der die Historien kombiniert, lässt Rebase deine Änderungen so aussehen, als wären sie nach den Remote-Updates entstanden. Mehr dazu in unserem Git-Rebase-Tutorial. 

Fazit

Git-Remotes sind essenziell für die kollaborative Entwicklung, denn sie verbinden lokale Repositories mit gemeinsamen Codebasen. In diesem Guide haben wir zentrale Remote-Operationen abgedeckt: Einrichtung, Synchronisation via Fetch-, Pull- und Push-Befehlen sowie das Management mehrerer Remote-Verbindungen.

Wenn du die hier behandelten Konzepte beherrschst, arbeitest du effizienter im Team, hältst die Projekt-Historie sauber und leistest stärkere Beiträge in der Entwicklung.

Weitere Infos zu Git-Remote-Branches findest du in den DataCamp-Ressourcen.

• Git Checkout Remote Branch: Schritt-für-Schritt-Anleitung 
• Tutorial: Git Push und Pull
• Git Pull Force: Einen lokalen Branch mit dem Remote überschreiben
• Introduction to Git Course
• Intermediate Git Course 
• Advanced Git Course
• Introduction to GitHub Concepts
• GitHub- und Git-Tutorial für Einsteiger
• Git lernen 2025: Der komplette Guide für Einsteiger
• Git Cheat Sheet