Bessere Zusammenarbeit mit Pull Requests

Dieser Artikel ist Teil unserer Serie „Advanced Git“. Folgen Sie uns unbedingt auf Twitter oder melden Sie sich für unseren Newsletter an, um über die nächsten Artikel informiert zu werden!

In diesem dritten Teil unserer Serie „Fortgeschrittenes Git“ befassen wir uns mit Pull-Requests – einem großartigen Feature, das sowohl kleinen als auch größeren Entwicklerteams hilft. Pull-Requests verbessern nicht nur den Überprüfungs- und Feedbackprozess, sondern helfen auch bei der Verfolgung und Diskussion von Codeänderungen. Last but not least sind Pull-Requests der ideale Weg, um zu anderen Repositories beizutragen, zu denen Sie keine Schreibberechtigung haben.

Was sind Pull-Requests?

Zunächst ist es wichtig zu verstehen, dass Pull-Requests keine Kernfunktion von Git sind. Stattdessen werden sie von der Git-Hosting-Plattform bereitgestellt, die Sie verwenden: GitHub, GitLab, Bitbucket, AzureDevops und andere verfügen über eine solche Funktionalität, die in ihre Plattformen integriert ist.

Warum sollte ich einen Pull-Request erstellen?

Bevor wir uns den Details widmen, wie man den perfekten Pull-Request erstellt, sprechen wir darüber, *warum* man dieses Feature überhaupt nutzen möchte.

Stellen Sie sich vor, Sie haben gerade eine neue Funktion für Ihre Software fertiggestellt. Vielleicht haben Sie in einem Feature-Branch gearbeitet, sodass Ihr nächster Schritt darin besteht, ihn in den Mainline-Branch (master oder main) zu mergen. Das ist in einigen Fällen völlig in Ordnung, zum Beispiel, wenn Sie der einzige Entwickler im Projekt sind oder wenn Sie erfahren genug sind und sicher wissen, dass Ihre Teammitglieder damit zufrieden sein werden.

Übrigens: Wenn Sie mehr über Branches und typische Branching-Workflows erfahren möchten, werfen Sie einen Blick auf unseren zweiten Artikel in unserer Serie „Fortgeschrittenes Git“: „Branching-Strategien in Git.“

Was aber, wenn Ihre Änderungen etwas komplexer sind und Sie möchten, dass jemand anderes Ihre Arbeit durchsieht? Dafür wurden Pull-Requests entwickelt. Mit Pull-Requests können Sie andere Personen einladen, Ihre Arbeit zu überprüfen und Feedback zu geben. 

Sobald ein Pull-Request offen ist, können Sie Ihren Code mit anderen Entwicklern besprechen. Die meisten Git-Hosting-Plattformen ermöglichen es anderen Benutzern, während dieses Prozesses Kommentare hinzuzufügen und Änderungen vorzuschlagen. Nachdem Ihre Prüfer Ihre Arbeit genehmigt haben, kann sie in einen anderen Branch gemergt werden.

Ein Überprüfungs-Workflow ist jedoch nicht der einzige Grund für Pull-Requests. Sie sind nützlich, wenn Sie zu anderen Repositories beitragen möchten, zu denen Sie keine Schreibberechtigung haben. Denken Sie an all die Open-Source-Projekte da draußen: Wenn Sie eine Idee für eine neue Funktion haben oder einen Patch einreichen möchten, sind Pull-Requests eine großartige Möglichkeit, Ihre Ideen vorzustellen, ohne dem Projekt beitreten und ein Hauptbeitragender werden zu müssen.

Das bringt uns zu einem Thema, das eng mit Pull-Requests verbunden ist: Forks.

Arbeiten mit Forks

Ein Fork ist Ihre persönliche Kopie eines bestehenden Git-Repositorys. Um auf unser Open-Source-Beispiel zurückzukommen: Ihr erster Schritt ist, einen Fork des ursprünglichen Repositorys zu erstellen. Danach können Sie Code in Ihrer eigenen, persönlichen Kopie ändern.

Nachdem Sie fertig sind, eröffnen Sie einen Pull-Request, um die Eigentümer des ursprünglichen Repositorys zu bitten, Ihre Änderungen zu übernehmen. Der Eigentümer oder einer der anderen Hauptbeitragenden kann Ihren Code überprüfen und dann entscheiden, ihn zu übernehmen (oder nicht).

Wichtiger Hinweis: Pull-Requests basieren immer auf Branches und nicht auf einzelnen Commits! Wenn Sie einen Pull-Request erstellen, basieren Sie ihn auf einem bestimmten Branch und bitten darum, dass er übernommen wird.

Das Leben eines Prüfers erleichtern: Wie man einen großartigen Pull-Request erstellt

Wie bereits erwähnt, sind Pull-Requests keine Kernfunktion von Git. Stattdessen hat jede Git-Plattform ihr eigenes Design und ihre eigene Vorstellung davon, wie ein Pull-Request funktionieren sollte. Sie sehen auf GitLab, GitHub, Bitbucket usw. unterschiedlich aus. Jede Plattform hat einen etwas anderen Workflow für die Nachverfolgung, Diskussion und Überprüfung von Änderungen.

Desktop GUIs wie der Tower Git-Client können dies beispielsweise erleichtern: Sie bieten eine *konsistente* Benutzeroberfläche, unabhängig davon, welchen Code-Hosting-Dienst Sie verwenden.

Das gesagt, der allgemeine Workflow ist immer derselbe und umfasst die folgenden Schritte

1. Wenn Sie keine Schreibberechtigung für das betreffende Repository haben, ist der erste Schritt, einen Fork zu erstellen, d. h. Ihre persönliche Version des Repositorys.
2. Erstellen Sie einen neuen lokalen Branch in Ihrem geforkten Repository. (Zur Erinnerung: Pull-Requests basieren auf Branches, nicht auf Commits!)
3. Nehmen Sie einige Änderungen in Ihrem lokalen Branch vor und committen Sie sie.
4. Pushen Sie die Änderungen in Ihr eigenes Remote-Repository.
5. Erstellen Sie einen Pull-Request mit Ihren Änderungen und starten Sie die Diskussion mit anderen.

Betrachten wir den Pull-Request selbst und wie man einen erstellt, der das Leben eines anderen Entwicklers erleichtert. Zunächst sollte er kurz sein, damit er schnell überprüft werden kann. Es ist schwieriger, Code zu verstehen, wenn man 3.000 Zeilen statt 30 Zeilen betrachtet. 

Stellen Sie außerdem sicher, dass Sie einen guten und selbsterklärenden Titel sowie eine aussagekräftige Beschreibung hinzufügen. Versuchen Sie zu beschreiben, *was* Sie geändert haben, *warum* Sie den Pull-Request geöffnet haben und *wie* Ihre Änderungen das Projekt beeinflussen. Die meisten Plattformen erlauben es Ihnen, einen Screenshot hinzuzufügen, der helfen kann, die Änderungen zu demonstrieren.

Genehmigen, mergen oder ablehnen?

Sobald Ihre Änderungen genehmigt wurden, können Sie (oder jemand mit Schreibberechtigung) den geforkten Branch in den Haupt-Branch mergen. Aber was ist, wenn der Prüfer den Pull-Request im aktuellen Zustand nicht mergen möchte? Nun, Sie können jederzeit neue Commits hinzufügen, und nachdem Sie diesen Branch gepusht haben, wird der bestehende Pull-Request aktualisiert.

Alternativ kann der Eigentümer oder jemand anderes mit Schreibberechtigung den Pull-Request ablehnen, wenn er die Änderungen nicht übernehmen möchte.

Sicherheitsnetz für Entwickler

Wie Sie sehen, sind Pull-Requests eine großartige Möglichkeit, mit Ihren Mitentwicklern zu kommunizieren und zusammenzuarbeiten. Indem Sie andere bitten, Ihre Arbeit zu überprüfen, stellen Sie sicher, dass nur qualitativ hochwertiger Code in Ihre Codebasis gelangt. 

Wenn Sie tiefer in fortgeschrittene Git-Tools eintauchen möchten, werfen Sie einen Blick auf mein (kostenloses!) „Advanced Git Kit“: Es ist eine Sammlung kurzer Videos zu Themen wie Branching-Strategien, Interaktiver Rebase, Reflog, Submodules und vieles mehr.