Teil 4 – Forken und Contributen in Open Source

Sep. 14, 2025

—

von

Warum Forken so wichtig ist

Eines der größten Versprechen von GitHub ist: Jeder kann mitmachen.
Ob Bugfix, neue Funktion oder Dokumentation – Open-Source-Projekte leben von Beiträgen der Community.
Aber: Fremden Entwicklern gibt man nicht einfach Schreibrechte auf das Hauptrepository.

👉 Lösung: Forks.
Ein Fork ist eine eigene Kopie eines Repositories unter deinem Account. Damit kannst du Änderungen machen, ohne das Original zu berühren.

Fork vs. Branch – der Unterschied

Branch: paralleler Entwicklungszweig im selben Repo.
Fork: vollständige Kopie in deinem eigenen GitHub-Account.

👉 Branches nutzt man, wenn man Schreibrechte auf das Repo hat (z. B. im Team).
👉 Forks nutzt man, wenn man von außen zu einem Projekt beitragen möchte.

Ein Repository forken

Gehe auf die Seite des Projekts (z. B. github.com/opensource/projekt).
Rechts oben: Klick auf Fork.
GitHub erstellt eine Kopie unter deinem Account: https://github.com/deinname/projekt.git

Jetzt hast du dein eigenes „Spielplatz-Repo“.

Den Fork lokal klonen

git clone https://github.com/deinname/projekt.git
cd projekt

Damit hast du eine Kopie auf deinem Rechner.

Upstream hinzufügen

Dein Fork kennt bisher nur „origin“ (dein Repo). Aber du willst auch mit dem Original synchron bleiben.

git remote add upstream https://github.com/opensource/projekt.git
git remote -v

👉 Jetzt hast du:

origin → dein Fork
upstream → das Original-Repo

Den typischen Contribution-Workflow

Neuen Branch erstellen git checkout -b feature-neues-feature
Änderungen machen & committen git add . git commit -m "Füge neues Feature hinzu"
Branch zu deinem Fork pushen git push origin feature-neues-feature
Pull Request erstellen
- Gehe auf dein Fork-Repo auf GitHub.
- GitHub zeigt oft direkt an: „Compare & Pull Request“.
- Ziel: upstream/main (Original), Quelle: dein Branch.
Review & Feedback
- Projekt-Maintainer prüfen deinen Code.
- Sie kommentieren, schlagen Änderungen vor.
- Du kannst nachbessern und den Branch erneut pushen.
Merge
- Wenn alles passt, wird dein PR ins Hauptrepo gemerged. 🎉

Beispiel: Bugfix beitragen

Ausgangslage

Du findest in einem Open-Source-Projekt einen Fehler:

In index.html fehlt ein Semikolon.

Ablauf

Repo forken.
Fork klonen.
Branch erstellen: git checkout -b fix/missing-semicolon
Fehler beheben, committen.
Branch pushen.
PR erstellen: „Fix: fehlendes Semikolon hinzugefügt“.

👉 Kleine, saubere PRs werden fast immer gern angenommen.

Best Practices beim Contributen

1. Lies die Contributing Guidelines

Viele Projekte haben eine CONTRIBUTING.md.

Wie Branches heißen sollen.
Commit-Message-Format (z. B. „feat:“, „fix:“).
Code-Style-Regeln.

👉 Halte dich daran – Maintainer lieben Contributors, die Regeln respektieren.

2. Kleine Pull Requests

Lieber 5 kleine PRs statt 1 riesigem.
Kleine PRs sind leichter zu reviewen und werden schneller gemerged.

3. Verknüpfe Issues mit PRs

Wenn dein PR ein Issue löst:

Fixes #123

in der PR-Beschreibung.
👉 Das Issue wird automatisch geschlossen, sobald der PR gemerged wird.

4. Tests nicht vergessen

Große Projekte haben Test-Suites.
Stelle sicher, dass dein Code alle Tests besteht.
Noch besser: Schreibe neue Tests für dein Feature.

5. Bleib synchron mit Upstream

Während du arbeitest, ändert sich oft das Original-Repo.

Hole regelmäßig Updates: git fetch upstream git checkout main git merge upstream/main
Danach deinen Branch neu darauf aufbauen: git rebase main

Warum Open Source beitragen?

Lernen: Du siehst, wie Profis arbeiten.
Reputation: Dein Profil auf GitHub zeigt deine Beiträge.
Netzwerk: Kontakte zu Maintainer-Teams.
Einfluss: Du gestaltest Software, die Millionen nutzen.

👉 Viele Entwickler haben ihre Karriere durch Open-Source-Beiträge auf GitHub gestartet.

Typische Stolperfallen

PR zu groß → Maintainer lehnen unübersichtliche PRs oft ab.
Direkt auf main gearbeitet → Immer Branches nutzen.
Fork nicht synchronisiert → Konflikte entstehen, PR hängt fest.
Keine Tests → PR wird blockiert.

👉 Tipp: Fang mit kleinen Bugfixes oder Dokumentationsbeiträgen an, um ein Gefühl für den Workflow zu bekommen.