Die Magie der Pull Requests

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

In der letzten Vorlesung haben wir gelernt, Branches auf dem eigenen lokalen Computer zusammenzuführen (merge). Das funktioniert hervorragend, wenn Sie allein arbeiten. Aber was, wenn ein ganzes Team am Projekt arbeitet? Wenn jede Person ihre Änderungen direkt in den Haupt-Branch main merged, beginnt schnell das Chaos: Jemand könnte versehentlich fehlerhaften Code hinzufügen, den Build brechen oder einen wichtigen Teil der Arbeit von Kolleginnen und Kollegen löschen.

Um das zu vermeiden, wird in der Teamentwicklung ein anderer Ansatz verwendet. Statt Änderungen sofort zu mergen, erstellen Sie einen Vorschlag zum Mergen. Dieser Vorschlag heißt Pull Request (kurz PR) oder, auf einigen Plattformen, Merge Request.

Pull Request ist eine offizielle Bitte: „Bitte holt (pull) meine Änderungen aus meinem Branch und fügt (merge) sie in den Haupt-Branch hinzu“. Aber es ist nicht nur eine Bitte, sondern eine ganze Plattform zur Diskussion, Prüfung und Verbesserung des Codes, bevor er in main landet.

2. Standard-Workflow mit Pull Request

Gehen wir Schritt für Schritt durch, wie ein typischer Workflow beim Erstellen einer neuen Funktionalität aussieht.

Bevor Sie einen Branch für eine neue Aufgabe erstellen, stellen Sie sicher, dass Sie alle Ihre abgeschlossenen Commits (push) übertragen und den Haupt-Branch main aktualisiert (Update Project) haben.

Andernfalls landen all Ihre „vergessenen“ lokalen Commits aus main versehentlich im neuen Pull Request und stiften Verwirrung bei Ihren Kolleginnen und Kollegen.

Schritt 1. Erstellen Sie einen Branch für die neue Aufgabe.

Wie zuvor beginnt jede neue Arbeit mit dem Anlegen eines separaten Branches. Angenommen, wir möchten unserem Projekt eine Datei mit Regeln für Contributor hinzufügen. Erstellen wir den Branch feature/add-contribution-guide.

Schritt 2. Nehmen Sie Änderungen vor und pushen Sie Ihren Branch zu GitHub.

Erstellen Sie im neuen Branch die Datei CONTRIBUTING.md (klicken Sie nach dem Erstellen auf Add) und schreiben Sie darin eine Botschaft an andere Entwicklerinnen und Entwickler. Anschließend führen Sie Commit and Push mit einer aussagekräftigen Nachricht aus, zum Beispiel: docs: Add contribution guide.

Das ist ein entscheidender Schritt! Ein Pull Request wird auf Basis eines Branches erstellt, der bereits auf dem Remote-Server existiert. Daher müssen Sie, bevor Sie den PR erstellen, Ihren neuen Branch nach GitHub pushen.

3. Einen Pull Request aus IntelliJ IDEA erstellen

Jetzt, da Ihr Branch auf GitHub vorhanden ist, können Sie einen Pull Request erstellen.

Schritt 1. Öffnen Sie den Tab Pull Requests.

Links in der IDE befindet sich der Tab Pull Requests. Öffnen Sie ihn und klicken Sie auf das Symbol +, um einen neuen PR zu erstellen.

Schritt 2. Füllen Sie die Angaben für den PR aus.

Die IDE öffnet automatisch eine praktische Oberfläche zum Erstellen des Pull Requests. Ihre Aufgabe ist es, sie sinnvoll auszufüllen. Schauen wir uns die wichtigsten Felder an:

1. Titel: Die IDE trägt hier oft den Branch-Namen ein, was jedoch eine schlechte Praxis ist. Der Titel sollte kurz, verständlich und den Kern der Änderungen widerspiegeln – wie eine gute Commit-Nachricht.
2. Beschreibung: hier erklären Sie, was und warum Sie gemacht haben.
3. Reviewer: hier wählen Sie eine oder mehrere Kolleginnen oder Kollegen, die Ihren Code prüfen sollen. Im Übungsprojekt überspringen wir diesen Schritt, aber in der Praxis ist er Pflicht.
4. Assignees: üblicherweise geben Sie hier sich selbst an. Das bedeutet, dass Sie Autor und hauptverantwortlich für diese Aufgabe sind sowie für die Einarbeitung von Änderungen nach dem Review.

Nachdem alle Felder ausgefüllt sind, klicken Sie auf Create Pull Request.

4. Code-Review: Prüfung und Diskussion

Nach dem Erstellen des PR beginnt der wichtigste Schritt – das Code-Review. Ihre Kolleginnen und Kollegen können Ihren PR öffnen, alle Änderungen ansehen und Kommentare hinterlassen.

Sie können alle Diskussionen direkt in der IDE im Tab Pull Requests sehen. Wenn jemand einen Kommentar hinterlässt, erhalten Sie eine Benachrichtigung.

Was tun, wenn um Änderungen gebeten wird?

Ganz einfach! Sie müssen keinen neuen PR erstellen. Nehmen Sie die erforderlichen Änderungen im Code in demselben Branch vor, erstellen Sie einen neuen Commit und pushen Sie ihn. Der Pull Request auf GitHub wird automatisch aktualisiert und enthält Ihre neuen Commits.

5. Abschluss: Mergen und Branch löschen

Wenn alle Anmerkungen behoben sind und das Team Ihre Änderungen genehmigt, kann der Pull Request gemergt werden. Üblicherweise macht das ein Senior-Entwickler oder Sie selbst, wenn Sie die Rechte haben.

Schritt 1. Merge

Das Mergen erfolgt meist auf der GitHub-Website. Dort erscheint unter Ihrem PR eine große grüne Schaltfläche Merge pull request. Nach dem Klick darauf wird Ihr Code Teil des Haupt-Branches main.

Schritt 2. Branch löschen.

Nach dem Merge wird Ihr `feature`-Branch nicht mehr benötigt, und Sie sollten ihn löschen, um das Repository sauber zu halten. GitHub schlägt dies selbst vor und zeigt die Schaltfläche Delete branch.

Vergessen Sie nicht, auch die lokale Kopie des Branches in Ihrer IDE zu löschen, um Ordnung zu halten. Das können Sie über dasselbe Menü zur Branch-Verwaltung erledigen.

6. Drei Commit-Regeln

Ein guter Commit besteht nicht nur aus einer passenden Nachricht, sondern auch aus dem richtigen Inhalt. Damit Ihre Änderungshistorie sauber, nützlich und professionell ist, halten Sie sich an drei einfache Regeln.

Regel 1: Verständliche Nachrichten nach Standard schreiben

Ihre Commits sind Nachrichten, die Sie an Ihr Team und an Ihr zukünftiges Ich senden. Eine Historie voller Nachrichten „fix“ oder „update“ ist völlig nutzlos. Der populärste Standard heißt Conventional Commits. Er schlägt folgende Struktur vor:

<Typ>: <kurze Beschreibung>

Typ – ein kurzes Wort, das die Kategorie Ihrer Änderungen beschreibt:

• feat: (feature) – für neue Funktionalität.
• fix: – zur Fehlerbehebung.
• docs: – für Änderungen an der Dokumentation.
• style: – für Formatierungsanpassungen, die die Logik des Codes nicht beeinflussen.
• refactor: – für Codeänderungen, die weder neue Funktionalität hinzufügen noch Fehler beheben.
• test: – zum Hinzufügen oder Korrigieren von Tests.
• chore: – für Routineaufgaben ohne direkten Codebezug (Aktualisieren von Abhängigkeiten, Build-Konfiguration).

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)

Versuchen Sie nicht, die Behebung eines Bugs, das Hinzufügen einer neuen Funktion und das Refactoring alten Codes in einen einzigen Commit zu packen. Ein solcher Commit ist sehr schwer zu überprüfen und fast unmöglich schmerzfrei rückgängig zu machen, falls etwas schiefgeht.

Jeder Commit sollte genau eine konkrete Aufgabe lösen.

• Schlecht: ein einziger Commit mit der Nachricht „Update user page“, der ein Feld für den Avatar hinzufügt, einen Fehler in der Namensvalidierung behebt und die Farbe der Buttons ä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 wesentlich einfacher zu verstehen und zu handhaben.

Regel 3: Ein Commit darf das Projekt nicht brechen

Jeder Commit im Haupt-Branch sollte das Projekt in funktionsfähigem Zustand hinterlassen. Bevor Sie ihn erstellen, sollten Sie sich zumindest vergewissern, dass der Code kompiliert. Aber wie stellen Sie sicher, dass Sie nicht versehentlich etwas in einem anderen Teil des Systems kaputt gemacht haben? Sich ausschließlich auf manuelle Prüfungen zu verlassen, ist riskant.

Hier hilft Automatisierung. In diesem Kurs richten wir keine automatischen Prozesse ein, aber Sie sollten wissen, wie das in realen Projekten funktioniert. Moderne Teams nutzen Systeme der kontinuierlichen Integration (Continuous Integration, CI), wie zum Beispiel GitHub Actions.

Wie funktioniert das?

Sie schreiben Code und die dazugehörigen Tests. Dann konfigurieren Sie einen speziellen Ablauf (Workflow) direkt auf GitHub. Sobald Sie einen Push in Ihren Pull Request senden, passiert Magie:

1. GitHub Actions erkennt dieses Ereignis und startet Ihren Workflow.
2. Es „baut“ das Projekt automatisch und führt alle Tests aus.
3. Wenn alle Tests erfolgreich sind, erscheint neben Ihrem Commit auf GitHub ein grünes Häkchen. Das ist das Signal für das gesamte Team, dass Ihre Änderungen sicher sind.
4. Wenn mindestens ein Test fehlschlägt, sehen Sie ein rotes Kreuz. Einen solchen PR in den Haupt-Branch zu mergen, ist strikt untersagt.

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

            subgraph Workflow
            C -- "Start" --> D[Tests_starten]
            D --> E[Erfolgreich]
            D --> F[Fehlgeschlagen]
            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
        

Benachrichtigungen lassen sich konfigurieren. Wenn Tests fehlschlagen, kann GitHub Actions eine E‑Mail an Sie oder an das gesamte Team senden. Dieser Ansatz schafft eine Kultur, in der Tests nicht nur Formalität sind, sondern ein integraler Bestandteil der Entwicklung, und jede Person Verantwortung für die Qualität ihres Codes übernimmt.