Git fortgeschritten: Remotes, Forks & Pull Requests

git-basics hat dir die lokale Arbeit gezeigt. Hier geht es um den zweiten Teil: wie du mit anderen zusammenarbeitest, ohne dir die Branches und Forks gegenseitig kaputtzumachen.

Lernziele

• Du verstehst Remotes, origin, upstream und den Unterschied
• Du beherrschst den Fork-Workflow inklusive Sync
• Du stellst und reviewst Pull Requests sauber

Remotes verstehen

Ein Remote ist nur ein Name für eine URL zu einem anderen Git- Repository. Mehrere Remotes sind erlaubt — das ist der Schlüssel zur Zusammenarbeit.

git remote -v
# origin    git@github.com:du/projekt.git  (fetch)
# origin    git@github.com:du/projekt.git  (push)

Üblich sind zwei Konstellationen:

flowchart LR
    subgraph "Direkte Mitarbeit (gleiches Repo)"
        L1[Lokal] -- "push/pull" --> O1[origin = Team-Repo]
    end
    subgraph "Fork-Workflow"
        L2[Lokal] -- "push/pull" --> O2[origin = dein Fork]
        L2 -. "fetch / rebase" .-> U[upstream = Original]
    end

Konvention:

• origin → dein eigenes Remote (Fork oder eigener Branch im Team-Repo)
• upstream → das Original, von dem du geforkt hast

Remotes verwalten

git remote add upstream git@github.com:original/projekt.git
git remote rename old neu
git remote remove veraltet
git remote set-url origin git@github.com:du/projekt.git

fetch vs pull

Empfehlung: git fetch + bewusst entscheiden, ob merge oder rebase passt. git pull ohne Nachdenken ist eine häufige Konfliktquelle.

Der Fork-Workflow

Ein Fork ist eine Kopie eines Repos in deinem Account. Du arbeitest darin frei und schlägst deine Änderungen per Pull Request zurück vor.

sequenceDiagram
    participant Du as Du
    participant Fork as origin (dein Fork)
    participant Upstream as upstream (Original)

    Du->>Upstream: 1. Fork erstellen (Klick auf GitHub)
    Du->>Fork: 2. git clone <fork>
    Du->>Du: 3. branch + commits
    Du->>Fork: 4. git push origin feature
    Du->>Upstream: 5. Pull Request öffnen
    Upstream-->>Du: 6. Review-Kommentare
    Du->>Fork: 7. Nachbessern + push
    Upstream->>Upstream: 8. PR mergen

Schritt für Schritt

# 1. Fork auf GitHub klicken
# 2. Lokal klonen
git clone git@github.com:du/projekt.git
cd projekt
 
# 3. Upstream-Verbindung anlegen
git remote add upstream git@github.com:original/projekt.git
 
# 4. Arbeit in einer neuen Branch
git switch -c feature/eigenes-thema
 
# 5. Commits, dann push in den Fork
git push -u origin feature/eigenes-thema
 
# 6. Auf GitHub: "Compare & pull request"

Fork mit upstream synchron halten

Wenn das Original sich weiterentwickelt, willst du deine Branch aktuell halten:

git fetch upstream                    # Originalstand holen
git switch main
git rebase upstream/main              # eigene main nachziehen
git push --force-with-lease origin main

--force-with-lease statt plain --force schützt dich davor, versehentlich Änderungen anderer im Remote zu überschreiben.

Merge-Strategien

Beim Mergen eines PRs hast du drei Varianten — die meisten Plattformen lassen dich pro Repo wählen, welche erlaubt sind.

flowchart TB
    subgraph "Merge Commit"
        M1[main] --> M2[A] --> M3[B] --> M4[C]
        M1 --> M5[merge-commit]
        M3 --> M5
    end
    subgraph "Squash"
        S1[main] --> S2[1 zusammengefasster Commit]
    end
    subgraph "Rebase Merge"
        R1[main] --> R2[A'] --> R3[B'] --> R4[C']
    end

Faustregel: Squash für 80 % der Feature-PRs. Merge Commit für große Branches mit echter Sub-Historie. Rebase Merge nur, wenn alle im Team wissen, was sie tun.

Draft Pull Requests

Du kannst PRs als Draft öffnen, bevor sie reviewfertig sind — sinnvoll für frühes Feedback oder um CI laufen zu lassen.

• Auf GitHub beim Öffnen: „Create draft pull request"
• Mit gh CLI: gh pr create --draft
• Markiert den PR sichtbar als „in Arbeit", verhindert versehentliches Mergen und signalisiert: Reviewer noch nicht aktiv anpingen.

Pull Requests — die richtige Hygiene

Ein guter PR ist klein, fokussiert und für den Reviewer einfach nachzuvollziehen.

Vor dem Öffnen

• Eine Sache pro PR — keine Misch-PRs aus Feature + Refactor + Tippfehler.
• Aktualisiere gegen main — git rebase upstream/main direkt vor dem Öffnen.
• Lokale Checks — Tests, Lint, Build sollten lokal grün sein.
• Sinnvolle Commit-Nachrichten — siehe nächster Abschnitt.

PR-Beschreibung — ein einfaches Template

## Was
 
Kurze Beschreibung der Änderung, eine Ebene über dem Diff.
 
## Warum
 
Welches Problem löst das? Welcher Bug? Welches Issue?
 
## Wie getestet
 
- [ ] Unit-Tests
- [ ] Manuelle Prüfung im Dev-Server
- [ ] Edge Cases X und Y geprüft
 
## Screenshots / Logs
 
Wenn UI oder Output sichtbar betroffen sind.

Commit-Nachrichten

Kurze Zusammenfassung in der Überschrift (max. 72 Zeichen)
 
Optionaler Body mit dem "Warum" und gegebenenfalls Hintergrund.
Hier können auch Issue-Referenzen stehen.
 
Fixes #123

Review — als Reviewer

Review — als Autor

• Atemzug-Regel wie bei Feedback: erst lesen, dann antworten.
• Nichts persönlich nehmen — Code wird kritisiert, nicht du.
• Bei Streit: Synchrones Gespräch (Call) statt 30 PR-Kommentare.
• Nach Anpassungen: Reviewer aktiv re-requesten, nicht warten.

Häufige Probleme

„Mein Push wird abgelehnt"

! [rejected] feature -> feature (non-fast-forward)

Meist: der Remote hat Commits, die du lokal nicht hast.

git fetch origin
git rebase origin/feature
git push origin feature

„Konflikt im PR"

git fetch upstream
git rebase upstream/main
# Konflikte auflösen
git add <gelöste-dateien>
git rebase --continue
git push --force-with-lease

„Versehentlich auf main commited"

git switch -c feature/wo-ich-hingehörte
git switch main
git reset --hard upstream/main
git switch feature/wo-ich-hingehörte

Praxis-Übung

Such dir ein kleines Open-Source-Projekt, das du bereits nutzt (z. B. eine Lieblings-Library oder ein Tool mit „good first issue"- Labels):

1. Fork das Repo.
2. Klone den Fork lokal.
3. upstream als Remote hinzufügen.
4. Korrigiere etwas Kleines (Tippfehler in der Doku zählt).
5. PR öffnen mit gutem Titel + Beschreibung.

Selbst wenn der PR nicht gemerged wird — du hast den Workflow einmal end-to-end durchlaufen.

Weiterführendes

• GitHub Docs: https://docs.github.com/de/pull-requests
• Conventional Commits: https://www.conventionalcommits.org/de/
• Linus Torvalds, Vortrag „Why Git": https://www.youtube.com/watch?v=4XpnKHJAok8

Gute Zusammenarbeit ist kein Werkzeug — sie ist eine Gewohnheit. 🤝