Teil 3 – Arbeiten mit Remote-Repositories (GitHub, GitLab, etc.)

Sep. 14, 2025

—

von

Warum Remote-Repositories wichtig sind

Bisher haben wir Git lokal genutzt: Repository anlegen, Dateien committen, Branches anlegen, Merges durchführen.
Aber in der Praxis arbeitet man fast nie allein. Teams wollen:

Code teilen
gemeinsam an Features entwickeln
Änderungen diskutieren und prüfen

Hier kommen Remote-Repositories ins Spiel: zentrale Orte, an denen der Code liegt, damit alle darauf zugreifen können.

Beliebte Plattformen

GitHub → der Platzhirsch, riesige Open-Source-Community.
GitLab → ähnlich wie GitHub, viele Enterprise-Features.
Bitbucket → stark in Unternehmensumgebungen.
Selbst gehostet → z. B. GitLab CE oder Gitea auf eigenem Server.

Alle diese Plattformen nutzen Git, unterscheiden sich aber in Zusatzfunktionen wie Issues, CI/CD, Wikis oder Code Reviews.

Dein erstes Remote-Repository

Auf GitHub ein Repo erstellen

Auf github.com einloggen.
Auf „New Repository“ klicken.
Namen vergeben (z. B. meinprojekt).
Optional: Beschreibung, README, Lizenz.
Auf „Create Repository“ klicken.

Ergebnis: eine URL, z. B.

https://github.com/maxmustermann/meinprojekt.git

Ein Remote zu deinem lokalen Repo hinzufügen

Wenn du schon ein lokales Repository hast:

git remote add origin https://github.com/maxmustermann/meinprojekt.git

👉 origin ist der Standardname für das Haupt-Remote.

Überprüfung:

git remote -v

Code hochladen (pushen)

Erst Commit(s) lokal erstellen.
Dann hochladen:

git push -u origin main

-u merkt sich, dass main mit origin/main verknüpft ist.
Danach reicht einfach:

git push

Code herunterladen (clonen & pullen)

Clonen

Wenn du ein fremdes Projekt von GitHub laden willst:

git clone https://github.com/maxmustermann/meinprojekt.git

👉 Ergebnis: Ein Ordner mit kompletter Historie, nicht nur aktuelle Dateien.

Pullen

Wenn andere Leute Änderungen gemacht haben:

git pull

Holt neue Commits vom Remote und integriert sie in deinen Branch.
Standardmäßig: fetch + merge.

Fetch vs. Pull

git fetch → lädt nur die neuen Commits herunter, integriert sie aber nicht.
git pull → macht automatisch fetch + merge.

👉 Empfehlung: Erst fetch, dann prüfen, dann selbst mergen.

Zusammenarbeit im Team

Branches auf Remote pushen

Wenn du an einem Feature arbeitest:

git checkout -b feature-login
git push -u origin feature-login

Jetzt können andere Teammitglieder deinen Branch sehen.

Pull Requests (GitHub) / Merge Requests (GitLab)

Statt Änderungen direkt in main zu pushen, erstellt man einen Pull Request (PR).

Du pushst deinen Branch.
Auf GitHub klickst du „New Pull Request“.
Dein Team kann den Code prüfen, kommentieren, Tests laufen lassen.
Erst danach wird gemerged.

👉 Vorteil: Qualitätssicherung, Diskussion, Transparenz.

Typische Workflows

Feature-Branch-Workflow
- Für jedes Feature ein Branch.
- PR/MR in main.
- Gut für kleine Teams.
GitFlow
- Strenger: main, develop, feature/*, release/*, hotfix/*.
- Komplex, aber nützlich für große Teams und Releases.
Trunk-Based Development
- Alles direkt in main, sehr kurze Branch-Lebenszeiten.
- Stark mit CI/CD kombiniert.

Konflikte beim Teamwork

Beispiel

Du und deine Kollegin ändern beide index.html.
Sie pusht zuerst.
Du willst pushen → Git meckert:

! [rejected] main -> main (fetch first)

Lösung

Änderungen ziehen:

git pull

Konflikte lösen (falls nötig).
Merge commit erstellen.
Erneut pushen.

Forks – das Open-Source-Modell

Bei Open-Source-Projekten hat man oft kein Schreibrecht auf dem Haupt-Repo. Lösung: Forks.

Du erstellst auf GitHub eine Kopie („Fork“) des Projekts in deinem Account.
Du arbeitest an deinem Fork.
Wenn du fertig bist, erstellst du einen Pull Request zurück ins Hauptprojekt.

👉 So kann jeder beitragen, ohne Chaos zu verursachen.

Nützliche Befehle für Remotes

Anzeigen aller Remotes:

git remote -v

Entfernen eines Remotes:

git remote remove origin

Branch vom Remote löschen:

git push origin --delete feature-login

Best Practices für Teamarbeit

Nie direkt auf main entwickeln.
→ Immer Branches nutzen, PRs erstellen.
Kleine PRs statt Monster-Änderungen.
→ Leichter zu reviewen.
Regelmäßig pullen/fetchen.
→ Verhindert große Konflikte.
Commit-Messages klar formulieren.
→ Teammitglieder verstehen Änderungen sofort.
CI/CD nutzen.
→ Automatische Tests vor dem Merge ausführen.