Dein erster Beitrag

Du hast ein Projekt gefunden und den Code verstanden. Jetzt wird’s ernst: Dein erster echter Beitrag.

🔄 Quick Recall: In der letzten Lektion hast du die 4-Ebenen-Navigation gelernt — vom Architekturüberblick bis zum konkreten Code. Jetzt wendest du dieses Wissen an und machst deinen ersten Beitrag.

Der Workflow: 6 Schritte

1. Fork    → Eigene Kopie des Repos erstellen
2. Clone   → Fork auf deinen Rechner holen
3. Branch  → Neuen Branch für deine Änderung erstellen
4. Commit  → Änderungen machen und committen
5. Push    → Branch in deinen Fork hochladen
6. PR      → Pull Request zum Original-Repo erstellen

Klingt nach viel? Ist es nicht. Nach ein paar Mal wird das zur Routine.

Schritt 1-3: Fork, Clone, Branch

# 1. Fork: Auf GitHub/GitLab den "Fork"-Button klicken

# 2. Clone: Deinen Fork klonen
git clone https://github.com/DEIN-NAME/projekt.git
cd projekt

# 3. Upstream hinzufügen (Original-Repo)
git remote add upstream https://github.com/ORIGINAL/projekt.git

# 4. Branch erstellen (beschreibender Name!)
git checkout -b fix/pagination-offset-42

Branch-Naming-Konventionen (prüfe die CONTRIBUTING.md!):

Prefix	Verwendung	Beispiel
`fix/`	Bugfix	`fix/pagination-offset-42`
`feat/`	Neues Feature	`feat/dark-mode-support`
`docs/`	Dokumentation	`docs/installation-guide-de`
`refactor/`	Code-Verbesserung	`refactor/extract-auth-module`

Schritt 4: Commit — Die Kunst der guten Message

Dein Commit erzählt eine Geschichte. Nicht WAS du geändert hast (das zeigt der Diff), sondern WARUM.

Aufbau einer guten Commit-Message:

Fix pagination offset in user list (#42)

The previous implementation used 0-based indexing for the page
parameter but the API expects 1-based indexing. This caused the
first page to be skipped when paginating through results.

Fixes #42

KI-Prompt für Commit-Messages:

„Schreibe eine Commit-Message für folgenden Diff: [Diff einfügen]. Format: Betreff (max 50 Zeichen, Imperativ, englisch), Leerzeile, Body mit dem WARUM der Änderung. Referenziere Issue #[Nummer]."

✅ Quick Check: Welche dieser Commit-Messages ist besser? A: „Fixed stuff" B: „Fix pagination offset in user list (#42)" (Antwort: B — beschreibend, im Imperativ, mit Issue-Referenz. A sagt niemandem etwas.)

Schritt 5-6: Push und PR

# Push deinen Branch
git push origin fix/pagination-offset-42

# Dann auf GitHub/GitLab: "Create Pull Request" klicken

Die PR-Beschreibung ist entscheidend — dazu kommt die nächste Lektion ausführlich.

Merge-Konflikte lösen

Passiert halt. Jemand hat dieselbe Stelle geändert, während du gearbeitet hast.

# Upstream-Änderungen holen
git fetch upstream
git rebase upstream/main

# Bei Konflikten:
# 1. Git zeigt die betroffenen Dateien
# 2. Öffne die Dateien — Konfliktstellen sind markiert:
#    <<<<<<< HEAD
#    Deine Änderung
#    =======
#    Upstream-Änderung
#    >>>>>>> upstream/main
# 3. Wähle die richtige Kombination
# 4. git add <datei>
# 5. git rebase --continue

KI-Prompt für Konfliktlösung:

„Ich habe einen Merge-Konflikt in [Datei]. Hier ist die Konfliktstelle: [Einfügen]. Erkläre mir, was beide Seiten tun und welche Kombination die richtige ist."

KI kann die Konfliktstellen erklären — aber die Entscheidung liegt bei dir. Du musst verstehen, warum du dich für welche Variante entscheidest.

Häufige Anfängerfehler

Fehler	Besser
Direkt auf `main` committen	Immer eigenen Branch erstellen
Riesiger Commit mit vielen Änderungen	Kleine, fokussierte Commits
„fix bug" als Message	Beschreibend mit WARUM und Issue-Referenz
Upstream nie synchronisieren	Regelmäßig `git fetch upstream`
Ungetesteter Code committen	Tests laufen lassen vor dem Commit

✅ Quick Check: Du hast drei Änderungen gemacht: einen Bugfix, eine Code-Verbesserung und eine Dokumentationsänderung. Wie viele Commits solltest du machen? (Antwort: Drei — einen pro logische Änderung. Kleine, fokussierte Commits sind einfacher zu reviewen und bei Problemen zurückzurollen.)

Rechtlicher Hinweis für Deutschland

§69b UrhG: Wenn du als Arbeitnehmer Code schreibst, hat dein Arbeitgeber die Verwertungsrechte. Kläre mit deinem Arbeitgeber, ob du während der Arbeitszeit oder mit Firmengeräten zu Open Source beitragen darfst.

CLAs (Contributor License Agreements): Manche Projekte verlangen eine CLA-Unterschrift vor dem ersten Beitrag. Das ist normal — lies sie trotzdem sorgfältig durch.

Key Takeaways

Der Standard-Workflow: Fork → Branch → Commit → Push → PR
Branch-Namen beschreibend mit Prefix (fix/, feat/, docs/)
Commit-Messages erklären das WARUM, nicht das WAS — im Imperativ, mit Issue-Referenz
Merge-Konflikte sind normal — KI hilft beim Verstehen, du entscheidest
§69b UrhG beachten: Arbeitgeber-Richtlinien für OSS-Beiträge klären

Up Next

In der nächsten Lektion lernst du, wie du Pull Requests schreibst, die Maintainer gerne mergen — mit KI-gestützten Beschreibungen und Code-Review.