Pull Request: So tragen Sie zu offenen Projekten bei

Was ist ein Pull Request?

Ein Pull Request ist eine Anfrage, Ihre Änderungen in den Hauptzweig des Projekts aufzunehmen. Stellen Sie sich vor, Sie haben ein interessantes Open-Source-Projekt gefunden, einen Fehler darin entdeckt oder eine Verbesserung gefunden. Sie können den Code im Repository einer anderen Person nicht direkt ändern, aber Sie können Ihre Änderungen über PR vorschlagen.

Der Prozess sieht so aus: Sie erstellen eine Kopie des Projekts, nehmen Änderungen an Ihrer Version vor und bitten dann den Projektbesitzer, Ihre Änderungen zu sich zu ziehen (pull). Daher der Name Pull Request.

Vorbereitung auf die Erstellung eines Pull Requests

Bevor Sie mit den Änderungen beginnen, ist es wichtig, sich richtig vorzubereiten.

Projekt studieren

Nehmen Sie sich Zeit, um das Projekt zu studieren, zu dem Sie beitragen möchten. Lesen Sie die README-Datei, studieren Sie die Struktur des Codes, sehen Sie sich die vorhandenen Pull Requests an - sowohl offene als auch bereits geschlossene. Dies hilft, den Kodierungsstil des Projekts und die Änderungsanforderungen zu verstehen.

Finde die Datei CONTRIBUTING

Viele Projekte haben eine CONTRIBUTING.md-Datei mit Regeln für die Einreichung von Beiträgen. Dort können die Codeanforderungen, der PR-Erstellungsprozess, die Einrichtung der Entwicklungsumgebung und andere wichtige Informationen beschrieben werden. Befolgen Sie unbedingt diese Regeln.

Überprüfen Sie die Probleme

Bevor Sie beginnen, überprüfen Sie den Abschnitt Probleme. Vielleicht arbeitet jemand bereits an einer ähnlichen Aufgabe oder Ihre Idee wurde bereits diskutiert. Wenn Sie einen Fehler beheben oder eine neue Funktion hinzufügen möchten, ist es am besten, zuerst ein Issue zu erstellen und dies mit den Maintainern zu besprechen.

Fork und Klonen des Repositorys

Der erste technische Schritt ist die Erstellung eines Projekt-Forks.

Erstellen Sie einen Fork

Auf GitHub geschieht dies mit einer einzigen "Fork"-Schaltfläche in der oberen rechten Ecke der Repository-Seite. Fork erstellt eine Kopie des Repositorys in Ihrem Konto, wo Sie frei experimentieren können.

Klonen Sie den Fork

Klonen Sie nun Ihren Fork auf einen lokalen Computer:

git clone https:// github.com/Ihr-Benutzername/Projektname.git
cd название-проекта

Fügen Sie Upstream Remote hinzu

Um Ihre Fork mit dem Original-Repository zu synchronisieren, fügen Sie sie als Upstream hinzu:

git remote add upstream https:// github.com/besitzer/projektnamen.git

Jetzt haben Sie zwei remote: origin (Ihre Fork) und upstream (das ursprüngliche Repository).

Erstellen eines Zweigs für Änderungen

Arbeiten Sie niemals direkt im Haupt- oder Master-Branch. Erstellen Sie immer einen separaten Zweig für jede Aufgabe:

git checkout -b fix-navigation-bug

Der Name des Zweigs sollte beschreibend sein und das Wesentliche der Änderungen widerspiegeln. Gute Beispiele: feature-add-dark-mode, fix-login-error, docs-update-readme.

Änderungen

Jetzt können Sie mit der Arbeit am Code beginnen.

Folgen Sie dem Stil des Projekts

Verwenden Sie den gleichen Codierungsstil wie im Projekt. Achten Sie auf Einrückungen, Variablenbenennung, Dateistruktur. Viele Projekte verwenden Linters und Formatierer - führen Sie diese vor dem Commit aus.

Machen Sie atomare Commits

Ein Commit ist eine logische Änderung. Dies vereinfacht die Code-Überprüfung und erleichtert das Rollback von Änderungen, falls erforderlich. Commit-Nachrichten sollten informativ sein:

git add .
git commit -m "Fixed a bug with navigation freezing when scrolling quickly"

Schlechte Nachricht: "Korrekturen" oder "Fix". Gut: beschreibt, was genau getan wurde und warum.

Schreiben Sie Tests

Wenn das Projekt Tests verwendet, stellen Sie sicher, dass Sie Tests für Ihren Code hinzufügen. Stellen Sie außerdem sicher, dass alle vorhandenen Tests bestanden werden:

npm test
# oder
pytest

Erstellen eines Pull Requests

Wenn die Änderungen fertig sind, senden Sie den Thread an Ihre Fork:

git push origin fix-navigation-bug

Jetzt wird auf GitHub in Ihrem Fork die Schaltfläche "Compare & pull request" angezeigt. Klicken Sie darauf.

Füllen Sie die PR-Beschreibung aus

Beschreibung Pull Request ist Ihre Chance zu erklären, was Sie getan haben und warum. Eine gute Beschreibung beinhaltet:

Was sich geändert hat: Kurzbeschreibung der Änderungen.

Warum: Erklärung des Grundes für die Änderungen, ggf. Verweis auf Issue.

Wie man testet: Anweisungen zum Überprüfen von Änderungen.

Screenshots: Wenn sich Änderungen auf die Benutzeroberfläche auswirken, fügen Sie Screenshots vor und nach den Änderungen hinzu.

Beispiel für eine Beschreibung:

# # Beschreibung
Исправлен баг с зависанием навигационного меню при быстрой прокрутке страницы.

# # Verwandte Probleme
Closes #234

# # Änderungen
- Добавлен debounce для обработчика скролла
- Оптимизирован расчёт позиции меню
- Добавлены unit-тесты для новой логики

# # Testen
1. Откройте страницу с длинным контентом
2. Быстро прокрутите вниз и вверх
3. Навигация должна плавно следовать за скроллом без задержек

Code-Review-Prozess

Nach der Erstellung des PR beginnt der Code-Review-Prozess.

Seien Sie bereit für Änderungen

Maintainer können Änderungen anfordern. Das ist normal und bedeutet nicht, dass Ihr Code schlecht ist. Code-Reviews helfen, die Qualität zu verbessern und die Konsistenz des Projekts aufrechtzuerhalten.

Antworten Sie auf Kommentare

Wenn der Rezensent einen Kommentar hinterlassen hat, antworten Sie darauf. Wenn Sie mit der Bemerkung einverstanden sind, nehmen Sie Änderungen vor. Wenn Sie nicht zustimmen, argumentieren Sie Ihre Position höflich und konstruktiv.

Nehmen Sie Änderungen am selben Thread vor

Alle zusätzlichen Commits in Ihrem Branch werden automatisch zu PR hinzugefügt:

# wir nehmen Änderungen vor
git add .
git commit -m "Code review comments taken into account: improved error handling"
git push origin fix-navigation-bug

Synchronisation mit dem Hauptzweig

Während die Überprüfung läuft, kann der Hauptzweig des Projekts vorankommen. Es ist wichtig, dass Ihr Zweig aktuell bleibt:

# Änderungen aus dem Original-Repository abrufen
git fetch upstream

# Wechseln Sie zu main
git checkout main

# Wir aktualisieren unser main
git merge upstream/main

# Wir kehren zu unserem Zweig zurück
git checkout fix-navigation-bug

# Änderungen aus main einfügen
git merge main

Wenn Konflikte auftreten, lösen Sie sie und machen Sie einen Commit.

Häufige Fehler und wie man sie vermeidet

Zu viel PR

Ein PR sollte eine Aufgabe lösen. Wenn Sie einen Fehler behoben und gleichzeitig eine neue Funktion hinzugefügt haben, teilen Sie dies in zwei separate PRs auf. Große PRs sind schwer zu überprüfen und werden seltener akzeptiert.

Änderungen in fremden Dateien

Ändern Sie keine Formatierung oder den Stil in Dateien, die sich nicht auf Ihre Aufgabe beziehen. Dies erzeugt Lärm in der PR und erschwert die Überprüfung.

Fehlende Beschreibung

PR ohne Beschreibung oder mit der Beschreibung "fix" wird kaum akzeptiert. Nehmen Sie sich Zeit für eine normale Beschreibung.

CI/CD ignorieren

Wenn im Projekt automatische Überprüfungen (Tests, Linters) konfiguriert sind, stellen Sie sicher, dass sie bestanden werden. PRs mit fehlgeschlagenen Tests werden nicht berücksichtigt.

Nach Annahme der PR

Wenn Ihr PR akzeptiert und in den Hauptbranch eingefügt wird, können Sie Ihren Arbeitsbranch löschen:

# lokal löschen
git branch -d fix-navigation-bug

# auf GitHub löschen
git push origin --delete fix-navigation-bug

Aktualisieren Sie Ihre Fork:

git checkout main
git pull upstream main
git push origin main

Tipps für Anfänger

Fangen Sie klein an

Versuchen Sie nicht, sofort eine große Refaktorierung durchzuführen. Beginnen Sie mit einfachen Aufgaben: Korrektur von Tippfehlern in der Dokumentation, kleinere Fehler, Hinzufügen von Beispielen. Dies wird Ihnen helfen, sich mit dem Prozess ohne unnötigen Stress vertraut zu machen.

Suchen Sie nach den Tags "good first issue"

Viele Projekte kennzeichnen Aufgaben, die für Anfänger geeignet sind, mit speziellen Tags: good first issue, beginner friendly, help wanted. Fangen Sie mit diesen an.

Scheuen Sie sich nicht, Fragen zu stellen

Wenn etwas unklar ist, fragen Sie in Issue oder im Projektchat. Die Open-Source-Community ist normalerweise freundlich zu Neulingen, die versuchen, es herauszufinden.

Seien Sie geduldig

Maintainer tun dies oft in ihrer Freizeit. Dein PR wird möglicherweise nicht sofort gesehen - das ist in Ordnung. Wenn mehr als eine Woche vergangen ist, können Sie höflich an sich selbst erinnern.

Etikette im Open-Source

Seien Sie höflich

Kommunizieren Sie respektvoll, auch wenn man Ihnen nicht zustimmt. Denken Sie daran, dass sich auf der anderen Seite des Bildschirms eine lebende Person befindet.

Nehmen Sie Kritik konstruktiv auf

Code-Review ist keine Kritik an Ihnen als Entwickler, sondern eine Möglichkeit, den Code zu verbessern. Nehmen Sie Kommentare als Gelegenheit, etwas Neues zu lernen.

Danken Sie für die Hilfe

Wenn dir jemand bei einem Problem geholfen oder sich Zeit für ein Review genommen hat, bedanke dich. Dies motiviert die Leute, weiterhin Zeit in das Projekt zu investieren.

Befund

Das Erstellen von Pull Requests ist eine Fähigkeit, die sich mit der Praxis entwickelt. Die erste PR mag beängstigend erscheinen, aber mit jedem weiteren Prozess wird es einfacher und natürlicher. Scheuen Sie sich nicht, Fehler zu machen – so lernen wir.

Die Teilnahme an Open-Source-Projekten verbessert nicht nur Ihre technischen Fähigkeiten, sondern öffnet auch Türen zur Entwickler-Community, hilft beim Aufbau eines Portfolios und beim Sammeln von Erfahrungen mit realen Projekten. Fangen Sie klein an, seien Sie geduldig und achten Sie auf Details — und schon bald werden Sie ein selbstbewusster Mitwirkender sein.

Kodik ist eine Bildungsplattform für angehende Entwickler, auf der Sie leicht verständliche Kurse zu Python, JavaScript, HTML, CSS und anderen gefragten Technologien finden.

Schließen Sie sich unserem Telegram-Kanal, wo wir nützliche Artikel teilen, komplexe Konzepte in einfacher Sprache erklären und Einsteigern helfen, ihre ersten Schritte in der Welt der Entwicklung zu machen.