Teil 2 – Repositories, Branches und Pull Requests in GitHub

Sep. 14, 2025

—

von

Stefan

in GitHub, IT Verwaltung

Warum diese drei Bausteine so wichtig sind

In GitHub dreht sich alles um Repositories, Branches und Pull Requests.

Repositories sind das Zuhause deines Codes.
Branches erlauben parallele Entwicklung.
Pull Requests machen Zusammenarbeit transparent.

Wer diese drei Dinge beherrscht, versteht bereits das Fundament von GitHub.

Repositories – mehr als nur ein Git-Ordner

Was ist ein Repository?

Ein Repository (kurz: „Repo“) ist ein Container für:

den gesamten Quellcode
die gesamte Historie (Commits, Branches, Tags)
Metadaten (Issues, PRs, Wiki, Discussions)

👉 Auf GitHub sind Repositories das zentrale Organisationsmittel.

Ein neues Repository erstellen

Auf GitHub einloggen.
„New Repository“ klicken.
Namen eingeben, z. B. meinprojekt.
Optional:
- Beschreibung hinzufügen.
- README.md automatisch anlegen lassen.
- .gitignore-Datei wählen (z. B. für Node.js, Python).
- Lizenz auswählen.
Auf „Create Repository“ klicken.

Du erhältst eine URL, z. B.:

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

Repo klonen oder verbinden

Wenn du ein neues Projekt startest: git clone https://github.com/maxmustermann/meinprojekt.git
Wenn du schon lokal arbeitest: git remote add origin https://github.com/maxmustermann/meinprojekt.git git push -u origin main

👉 Ab jetzt ist dein lokales Git-Repo mit GitHub verbunden.

Branches – parallele Entwicklungszweige

Warum Branches?

Stell dir vor, dein Projekt ist ein Baum:

Der Hauptstamm heißt meistens main.
Jeder neue Zweig ist ein Branch.
Du kannst am Branch arbeiten, ohne den Stamm zu beschädigen.

Das macht Branches so mächtig: mehrere Leute können gleichzeitig arbeiten.

Branch erstellen und wechseln

git branch feature-login
git switch feature-login

👉 Du arbeitest jetzt in feature-login, während main unverändert bleibt.

Branches auf GitHub

Alle Branches werden auch im GitHub-Webinterface angezeigt. Dort sieht man:

welche Branches aktiv sind
wann sie zuletzt geändert wurden
welche noch offene Pull Requests haben

Branch-Strategien

Feature-Branches → für neue Funktionen.
Hotfix-Branches → für dringende Fehlerbehebungen.
Release-Branches → zur Vorbereitung von Versionen.

👉 Best Practice: Nie direkt auf main entwickeln.

Pull Requests – Herzstück der Zusammenarbeit

Was ist ein Pull Request (PR)?

Ein PR ist ein Vorschlag, Änderungen von einem Branch in einen anderen zu übernehmen.

Du erstellst Änderungen in deinem Feature-Branch.
Du pushst diesen Branch zu GitHub.
Du klickst auf „New Pull Request“.
Dein Team kann nun:
- den Code ansehen
- Kommentare schreiben
- Fragen stellen
- Änderungen anfordern
- automatisierte Tests prüfen

👉 Erst wenn der PR akzeptiert wird, fließt er in main.

Workflow mit Pull Requests

Branch erstellen git checkout -b feature-login
Änderungen machen und committen git add login.html git commit -m "Füge Login-Seite hinzu"
Branch pushen git push -u origin feature-login
PR auf GitHub erstellen
- Über die Weboberfläche: „Compare & Pull Request“.
- Ziel: main, Quelle: feature-login.
Review & Diskussion
- Teammitglieder prüfen Code und Tests.
Merge
- Wenn alles ok ist: Merge in main.

PR-Optionen auf GitHub

Merge Commit → alle Commits bleiben erhalten.
Squash and Merge → Commits werden zu einem einzigen zusammengefasst.
Rebase and Merge → Historie wird linear, ohne Merge-Commit.

👉 Teams legen oft Regeln fest, welche Merge-Strategie erlaubt ist.

Praktisches Beispiel

Ausgangslage

Projekt mit main-Branch.
Neue Funktion „Login-Seite“ soll entstehen.

Ablauf

Entwickler A erstellt Branch feature-login.
Arbeitet am Code, macht mehrere Commits.
Pusht Branch zu GitHub.
Erstellt einen Pull Request.
Entwickler B überprüft Änderungen:
- Gibt Feedback: „Bitte Passwortfeld verschlüsseln“.
- Kommentiert direkt im Code.
A verbessert den Code, pusht erneut.
Automatisierte Tests (GitHub Actions) laufen.
PR wird akzeptiert und gemerged.

👉 Ergebnis: main bleibt stabil, Feature kommt sauber integriert hinzu.

Pull Requests und Open Source

PRs sind auch der Schlüssel für Open-Source-Beiträge:

Du forkt ein Projekt (dazu mehr in Teil 4).
Machst Änderungen in deinem Fork.
Schickst einen PR zurück zum Hauptprojekt.

👉 Genau so arbeiten tausende Entwickler weltweit an Projekten wie React, Linux oder Kubernetes.

Best Practices

Branch-Namen klar wählen
- feature/login-form
- bugfix/session-timeout
Kleine PRs statt riesiger Änderungen
- Leichter zu reviewen.
Commit-Messages klar formulieren
- „Fix: Fehler bei Passwort-Hashing behoben“ statt „Update“.
Automatisierte Checks aktivieren
- Jeder PR sollte Tests durchlaufen.