Die Magie von Pull Requests

1. Vom Merge zum Vorschlag: warum braucht man Pull Requests?

In der letzten Vorlesung haben wir gelernt, Branches auf dem lokalen Rechner zu mergen. Das funktioniert prima, wenn du allein arbeitest. Aber was, wenn an einem Projekt ein ganzes Team arbeitet? Wenn jeder seine Änderungen direkt in den Hauptbranch main merged, entsteht schnell Chaos: jemand könnte versehentlich fehlerhaften Code einbringen, den Build kaputtmachen oder wichtige Arbeit von Kolleg:innen löschen.

Um das zu vermeiden, gibt es in der Teamarbeit einen anderen Ansatz. Statt Änderungen sofort zu mergen, erstellst du einen Vorschlag zum Mergen. Dieser Vorschlag heißt Pull Request (kurz PR) oder auf manchen Plattformen Merge Request.

Pull Request — das ist eine formelle Bitte: "Bitte pullt meine Änderungen aus meinem Branch und merged sie in den Hauptbranch". Aber es ist nicht nur eine Bitte, sondern eine Plattform zum Diskutieren, Prüfen und Verbessern des Codes, bevor er in main landet.

2. Standard-Workflow mit Pull Requests

Lass uns Schritt für Schritt durchgehen, wie ein typischer Workflow beim Entwickeln einer neuen Funktion aussieht.

Bevor du einen Branch für eine neue Aufgabe erstellst, stell sicher, dass du alle fertigen Commits gepusht (push) und den Hauptbranch main aktualisiert (Update Project) hast.

Sonst könnten deine "vergessenen" lokalen Commits aus main versehentlich in den neuen Pull Request gelangen und Verwirrung im Team stiften.

Schritt 1. Erstelle einen Branch für die neue Aufgabe.

Wie immer beginnt neue Arbeit mit einem separaten Branch. Angenommen, wir wollen eine Datei mit Regeln für Contributor zum Projekt hinzufügen. Erstelle den Branch feature/add-contribution-guide.

Schritt 2. Mach die Änderungen und push deinen Branch zu GitHub.

Im neuen Branch erstellst du die Datei CONTRIBUTING.md (nach dem Erstellen auf Add klicken) und schreibst dort eine Nachricht an andere Entwickler:innen. Danach machst du ein Commit and Push mit einer verständlichen Nachricht, z. B.: docs: Add contribution guide.

Das ist ein wichtiger Schritt! Ein Pull Request basiert auf einem Branch, der bereits auf dem Remote existiert. Deshalb musst du deine neue Branch zuerst zu GitHub pushen, bevor du den PR erstellst.

3. Einen Pull Request aus IntelliJ IDEA erstellen

Jetzt, wo dein Branch auf GitHub ist, kannst du einen Pull Request erstellen.

Schritt 1. Öffne das Tab Pull Requests.

Links in der IDE gibt es das Tab Pull Requests. Öffne es und klicke auf das +-Icon, um einen neuen PR zu erstellen.

Schritt 2. Fülle die PR-Daten aus.

Die IDE öffnet automatisch ein komfortables Interface zum Erstellen des Pull Requests. Deine Aufgabe ist, die Felder sinnvoll auszufüllen. Schauen wir uns die wichtigsten Felder an:

1. Titel: Die IDE schlägt oft den Branchnamen vor, das ist aber keine gute Praxis. Der Titel sollte kurz, verständlich und aussagekräftig sein — ähnlich einer guten Commit-Message.
2. Beschreibung: hier erklärst du, was und warum du etwas geändert hast.
3. Reviewer: hier wählst du eine oder mehrere Kolleg:innen aus, die deinen Code überprüfen sollen. Im Lernprojekt können wir diesen Schritt überspringen, in echten Projekten ist er aber Pflicht.
4. Assignees: normalerweise trägst du dich selbst ein. Das bedeutet, dass du der Autor und primär Verantwortliche für die Aufgabe und für etwaige Änderungen nach dem Review bist.

Wenn alle Felder ausgefüllt sind, klick ruhig auf Create Pull Request.

4. Code-Review: Prüfung und Diskussion

Nach dem Erstellen des PR beginnt die wichtigste Phase — das Code-Review (code review). Deine Kolleg:innen können den PR öffnen, alle Änderungen ansehen und Kommentare hinterlassen.

Du kannst alle Diskussionen direkt in der IDE im Tab Pull Requests sehen. Wenn jemand einen Kommentar hinterlässt, bekommst du eine Benachrichtigung.

Was tun, wenn man dich um Änderungen bittet?

Ganz einfach! Du musst keinen neuen PR erstellen. Mach die gewünschten Änderungen im selben Branch, committe sie und push sie. Der Pull Request auf GitHub aktualisiert sich automatisch und enthält dann deine neuen Commits.

5. Abschluss: Mergen und Branch löschen

Wenn alle Anmerkungen behoben sind und das Team deine Änderungen freigegeben hat, kann der Pull Request gemerged werden. Meistens macht das ein Senior Developer oder du selbst, falls du die Rechte hast.

Schritt 1. Merge

Das Mergen passiert meistens auf der GitHub-Webseite. Dort erscheint unter deinem PR ein großer grüner Button Merge pull request. Nach dem Klick wird dein Code Teil des Hauptbranches main.

Schritt 2. Branch löschen.

Nach dem Merge wird dein feature-Branch in der Regel nicht mehr gebraucht und sollte gelöscht werden, damit das Repo nicht zugemüllt wird. GitHub bietet nach dem Merge einen Button Delete branch dafür an.

Vergiss nicht, auch die lokale Kopie des Branches in deiner IDE zu löschen, um Ordnung zu halten. Das geht über das Branch-Management-Menü.

6. Drei Commit-Regeln

Ein guter Commit ist nicht nur eine gute Message, sondern auch guter Inhalt. Damit die Historie sauber, nützlich und professionell bleibt, halte dich an drei einfache Regeln.

Regel 1: Schreibe verständliche Messages nach einem Standard

Deine Commits sind Nachrichten an dein Team und an dein zukünftiges Ich. Eine Historie voller "fix" oder "update" ist völlig nutzlos. Der bekannteste Standard heißt Conventional Commits. Er schlägt diese Struktur vor:

<type>: <kurze Beschreibung>

Type — ein kurzes Wort, das die Kategorie der Änderung beschreibt:

• feat: (feature) — für neue Funktionalität.
• fix: — für Bugfixes.
• docs: — für Änderungen an der Dokumentation.
• style: — für Formatierungsänderungen, die die Logik nicht beeinflussen.
• refactor: — für Codeänderungen, die keine neue Funktion hinzufügen und keine Bugs fixen.
• test: — für das Hinzufügen oder Anpassen von Tests.
• chore: — für Routineaufgaben, die nicht direkt mit dem Code zu tun haben (Dependencies updaten, Build-Setup).

Beispiele:

• Schlecht: fixed bug
• Gut: fix: Correct user login validation

• Schlecht: readme
• Gut: docs: Update installation instructions

Regel 2: Ein Commit — eine logische Änderung (Atomarität)

Versuche nicht, Bugfix, neue Feature und Refactor in einem Commit zu kombinieren. Solche Commits sind schwer zu reviewen und fast unmöglich schmerzfrei zurückzunehmen, falls etwas schiefgeht.

Jeder Commit sollte genau eine konkrete Aufgabe lösen.

• Schlecht: ein Commit mit der Message "Update user page", der ein Avatar-Feld hinzufügt, einen Validierungsbug repariert und Button-Farben ändert.
• Gut: drei separate Commits:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Kleine, fokussierte Commits sind viel einfacher zu verstehen und zu managen.

Regel 3: Ein Commit darf das Projekt nicht kaputtmachen

Jeder Commit im Hauptbranch sollte das Projekt in einem lauffähigen Zustand hinterlassen. Vor dem Erstellen solltest du mindestens sicherstellen, dass der Code kompiliert. Aber wie stellst du sicher, dass du nicht versehentlich etwas in einem anderen Teil des Systems kaputtgemacht hast? Dich nur auf manuelle Checks zu verlassen ist riskant.

Hier hilft dir Automatisierung. In diesem Kurs richten wir keine automatischen Prozesse ein, aber du solltest wissen, wie das in echten Projekten funktioniert. Moderne Teams nutzen Continuous Integration (CI) Systeme wie GitHub Actions.

Wie funktioniert das?

Du schreibst Code und Tests dazu. Dann konfigurierst du ein Workflow-Skript direkt auf GitHub. Sobald du in deinen Pull Request pushst, passiert die Magie:

1. GitHub Actions erkennt das Event und startet deinen Workflow.
2. Es baut das Projekt automatisch und führt alle Tests aus.
3. Wenn alle Tests bestanden sind, erscheint neben deinem Commit auf GitHub ein grünes Häkchen. Das signalisiert dem Team, dass deine Änderungen sicher sind.
4. Fällt mindestens ein Test durch, siehst du ein rotes Kreuz. Einen solchen PR in den Hauptbranch zu mergen ist strikt verboten.

            graph LR
            subgraph GitHub
            A[Entwickler] -- "push" --> B(Repository)
            B -- "Event: push" --> C{GitHub Actions}
            end

            subgraph Workflow
            C -- "Start" --> D[Run_Tests]
            D --> E[Erfolgreich]
            D --> F[Nicht erfolgreich]
            end

            subgraph Notifications
            F --> G((Email))
            G --> H[Entwickler]
            G --> I[Team]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

Man kann Benachrichtigungen konfigurieren. Wenn Tests fehlschlagen, kann GitHub Actions eine E-Mail an dich oder an das ganze Team senden. Dieser Ansatz schafft eine Kultur, in der Tests nicht nur Formalität sind, sondern ein integraler Bestandteil der Entwicklung — und jeder ist für die Qualität seines Codes verantwortlich.