Beitragen zu Open-Source-Projekten

In diesem Artikel erfährst du, wie du an einem Open-Source-Projekt mitwirkst, indem du ein Beispiel durcharbeitest. Wir führen dich durch einen Beitrag zum github/docs-Repository: Mache dich mit dem Repository vertraut, suche einen Bereich zum Beitragen, erstelle und übermittle einen Pull Request, und arbeite mit Maintainern zusammen, um deine Änderungen akzeptieren zu lassen.

Orientierung an den Projektrichtlinien

Bevor du beginnst, ist es wichtig, die Richtlinien und Anforderungen des Projekts zu verstehen.

Warum sind Richtlinien wichtig?

Jedes Projekt verfügt über eigene Konventionen, Programmierstandards und Mitwirkungsprozesse, die du befolgen musst:

• Anforderungen an Codestil und -formatierung: Formatieren von Code, Namenskonventionen und Lintingregeln
• Testrichtlinien: Ausführen von Tests, erforderliche Tests für neue Features und Testkonventionen
• Pull-Request-Prozess: Strukturieren deines Pull Requests, einzuschließende Informationen und zu erfüllende Erwartungen
• Entwicklungssetup: Einrichten der lokalen Entwicklungsumgebung, erforderlichen Abhängigkeiten und Buildprozesse
• Problemberichterstattung: Melden von Fehlern, Anfordern von Features oder Stellen von Fragen
• Kommunikationskanäle: Stellen von Fragen, Diskutieren von Änderungen oder Hilfesuchen bei Maintainern

Wenn du dir diese durchliest, sparen sowohl du als auch die Maintainer Zeit, und es wird wahrscheinlicher, dass dein Beitrag akzeptiert wird.

Finden der Richtlinien

Um auf diese Richtlinien und Anforderungen zuzugreifen, navigiere auf der Registerkarte Insights zur Checkliste Community Standards. In unserem Beispiel verwenden wir die github/docs Community Standards.

• Infodatei: Bietet eine Übersicht über das Projekt. Der Inhalt kann variieren, aber die Infodatei hilft Benutzern und Mitwirkenden, schnell zu verstehen, was das Projekt ist und wie es verwendet wird, zusammen mit Links zu anderen Dokumentationen.

• Verhaltensregeln: Definiert akzeptable Verhaltensstandards für Projektmitwirkende und Communitymitglieder und legt Erwartungen und Verfahren zum Umgang mit Verstößen fest.

• Mitwirkenden: Enthält Richtlinien und Anweisungen für Mitwirkende am Projekt. Sie hilft dabei, den Beitragsprozess zu optimieren, indem klare Erwartungen gesetzt werden und eine konsistente Zusammenarbeit gefördert wird.

• Lizenz: Definiert rechtlich, wie andere Benutzer den Code verwenden, ändern und verteilen können, und schützt sowohl die Maintainer als auch die Benutzer, indem eindeutige Bedingungen für Copyright und Berechtigungen festgelegt werden.

  • Beispielsweise verwendet das github/docs-Repository die Creative Commons-Lizenz für die Dokumentation, bei der es sich um einen Lizenztyp handelt, der speziell für kreative Arbeiten bestimmt ist. Der Softwarecode in github/docs befindet sich unter der MIT-Lizenz, bei der es sich um eine eingeschränkte Lizenz handelt, mit der jeder den darin enthaltenen Code verwenden kann.
  • Weitere Informationen zu anderen gängigen Lizenztypen findest du mit dem Tool Choose a license.

• Sicherheitsrichtlinie: Enthält Anweisungen zum Melden von Sicherheitsrisiken an Maintainer des Repositorys.

Überprüfe jede der Ressourcen, die für das github/docs-Repository verfügbar sind.

Finden eines Mitwirkungsbereichs

Wenn du zum ersten Mal an einem Projekt mitwirkst, kannst du dich mit kleineren Korrekturen wie Verbesserungen der Dokumentation oder kleinen Fehlerberichten mit der Codebasis und dem Mitwirkendenworkflow vertraut machen. In diesem Beispiel suchst du nach Issues mithilfe der help wanted- und good first issue-Bezeichnungen, um bestimmte Issues anzuzeigen, die für externe Mitwirkende offen sind. Anschließend verwendest du Copilot, um Kontext zum Issue zu liefern.

1. Navigiere zur Registerkarte Issues des github/docs-Repositorys, verwende dann den Filter Labels, und wähle „help wanted“ aus, um offene Issues anzuzeigen, die Maintainer speziell als „needing community help“ markiert haben.

2. Gehe die Liste der Issues durch, und suche nach einem Issue, an dem du arbeiten möchtest.

3. Klicke oben rechts auf einer beliebigen Seite auf GitHub auf das Symbol neben der Suchleiste.

   Der ganzseitige, immersive Modus von Copilot Chat wird angezeigt.

4. Gib im Promptfeld den folgenden Prompt ein:

   Text

   Can you summarize the key points and next steps from this issue?
   

5. Lies den bereitgestellten Kontext von Copilot und die Kommentare anderer Mitwirkender und Maintainer, um festzustellen, ob das Issue eines ist, an dem du arbeiten möchtest. Wenn du bestimmte Fragen hast, kannst du sie direkt im Issue oder im Discord-, IRC- oder Slack-Kanal des Projekts stellen, falls vorhanden.

Erstellen einer eigenen Kopie eines Projekts

Jetzt kannst du mit deinem Beitrag beginnen. Da du keinen Zugriff zum Bearbeiten des Repositorys hast, musst du zuerst einen Fork erstellen: deine eigene Kopie des Repositorys, in der du sicher Änderungen vornehmen und zum Maintainer-Review zurücksenden kannst. In diesem Beispiel wird das Erstellen eines Forks des github/docs-Repositorys erläutert.

1. Navigiere zum GitHub Docs-Projekt auf https://github.com/github/docs.

2. Klicke in der oberen rechten Ecke der Seite auf Forken.

3. Wähle unter „Besitzer“ das Dropdownmenü und dann einen Besitzerin für das geforkte Repository aus.

4. Standardmäßig erhalten Forks den gleichen Namen wie die zugehörigen Upstream-Repositorys. Um deinen Fork noch genauer zu unterscheiden, kannst du optional im Feld „Repositoryname“ einen Namen eingeben.

5. Gib optional im Feld „Beschreibung“ eine Beschreibung für deinen Fork ein.

6. Wähle optional Nur Standardbranch kopieren aus.

   Bei vielen Forkszenarien, z. B. Beiträge zu Open-Source-Projekten, musst du nur den Standardbranch kopieren. Wenn du diese Option nicht auswählst, werden alle Branches in den neuen Fork kopiert.

7. Klicke auf Fork erstellen.

Klonen eines Forks eines Projekts

Jetzt hast du einen Fork des github/docs-Repositorys unter deinem Konto, aber du musst es auf deinen lokalen Computer bringen, um mit der Bearbeitung deiner Änderungen zu beginnen.

1. Navigiere auf GitHub im github/docs-Repository zu deinem Fork.

2. Klicke oberhalb der Liste der Dateien auf Code.

   

3. Kopiere die URL für das Repository.

   • Um ein Repository über HTTPS zu klonen, klicke unter „HTTPS“ auf .

   • Wenn du das Repository mithilfe eines SSH-Schlüssels klonen möchtest, einschließlich eines Zertifikats, das von der SSH-Zertifizierungsstelle deiner Organisation ausgestellt wurde, wähle SSH und dann aus.

   • Um ein Repository über die GitHub CLI zu klonen, klicke auf GitHub CLI und dann auf .

     

4. Öffne unter Mac oder Linux „Terminal“. Öffnen unter Windows „Git Bash“.

5. Ändere das aktuelle Arbeitsverzeichnis zum Speicherort, in dem Du das geklonte Verzeichnis haben willst.

6. Gib git clone ein, und füge dann die zuvor kopierte URL ein. Sie sieht wie folgt aus (anstelle von YOUR-USERNAME wird dein GitHub-Benutzername verwendet):

   Shell

   git clone https://github.com/YOUR-USERNAME/docs
   

7. Drücken Sie die EINGABETASTE. Dein lokaler Klon wird erstellt.

Vornehmen von Änderungen in einem Topic-Branch

Jetzt ist es an der Zeit, Änderungen vorzunehmen! Bevor du beginnst, empfiehlt es sich, einen Topic-Branch mit einem beschreibenden Namen in deinem Fork zu erstellen. Mithilfe eines Topic-Branchs kannst du deine Arbeit vom Standardbranch des Repositorys trennen.

git checkout -b YOUR_TOPIC_BRANCH

git checkout -b YOUR_TOPIC_BRANCH

Öffne nach dem Wechsel zu deinem Topic-Branch deinen bevorzugten Text-Editor oder deine bevorzugte IDE, und beginne mit dem Programmieren. Befolgen Sie diese bewährten Methoden:

• Verwende Copilot für Codevorschläge, um zuversichtlich Änderungen vorzunehmen.
• Dokumentiere deinen Code, und schreibe Tests. Diese werden häufig übersehen und können dazu beitragen, dass dein Beitrag gemergt wird.
• Stelle Copilot Fragen zu dem Problem, damit du die Anforderungen für die Implementierung besser verstehst.
• Verwende Copilot, um deine Änderungen zu überprüfen, um sicherzustellen, dass sie dem Programmierstil und den Dokumentationsanforderungen des Projekts entsprechen.
• Verwende Copilot, um Anweisungen zum Erstellen und Testen des Projekts auf deinem lokalen Computer zu erhalten.

Commit und Push deiner Änderungen

Wenn deine Änderungen bereit sind, kannst du sie in deinem Repository stagen und committen. Verwende beim Schreiben einer Commitnachricht einen aussagekräftigen, präzisen Committitel mit weniger als 50 Zeichen, der die Funktionsweise des Commits zusammenfasst. Gruppiere zusammengehörige Änderungen nach Möglichkeit in einzelnen Commits, aber halt nicht zusammenhängende Änderungen in separaten Commits.

git add .
git commit -m "a short description of the change"

git add .
git commit -m "a short description of the change"

Versuche, Commitbeschreibungszeilen unter 72 Zeichen zu halten, um die Lesbarkeit zu verbessern. Wenn du mit dem Committen deiner lokalen Änderungen fertig und bereit bist, sie an GitHub zu pushen, pushe deine Änderungen an das Remoterepository.

git push

git push

Übermitteln eines Pull Requests

Nachdem du die Änderungen nun an GitHub gepusht hast, kannst du einen Pull Request öffnen. Du kannst einen Pull Request zum Review öffnen, auch wenn die Änderungen, die du in deinem Branch vorgenommen hast, noch nicht final sind. Das frühzeitige Öffnen eines Pull Requests im Beitragsprozess macht die Maintainer aufmerksam und ermöglicht es ihnen, erstes Feedback zu deinen Änderungen zu geben.

1. Wechsle zu deinem geforkten Repository auf GitHub. Beispiel: https://github.com/YOUR-USERNAME/docs.
2. Für deinen kürzlich gepushten Branch sollte die Aufforderung „Compare & pull request“ angezeigt werden. Klicken Sie darauf.
3. Wenn nicht, wechsle zur Registerkarte „Pull Requests“, und klicke auf „New pull request“.
4. Stelle sicher, dass das Basisrepository github/docs und der Basisbranch der Mainbranch (z. B. main) ist.
5. Stelle sicher, dass es sich bei dem Head-Repository um deinen Fork (YOUR-USERNAME/docs) handelt und dass der Vergleichsbranch dein Branch ist.
6. Gib einen Titel und eine Beschreibung für Deinen Pull Request ein. Verweise in der Beschreibung auf das Issue, das durch deinen Pull Request geschlossen wird. Beispiel: Closes: #15. Dadurch wird der Kontext für deinen Pull Request bereitgestellt, und das Issue wird automatisch geschlossen, sobald der Pull Request gemergt wurde.

Arbeiten mit Projektmaintainern

Sobald dein Pull Request übermittelt wurde, besteht der nächste Schritt darin, dass ein Projektmaintainer es überprüft und Feedback gibt. Projektverwalter können Änderungen anfordern, die dem Stil oder der Architektur der Codebasis entsprechen. Manchmal musst du einen erheblichen Teil deiner Arbeit umgestalten.

• Wenn Feedback zu deinem Pull Request eingeht, antworte umgehend und professionell, auch wenn scharfe Kritik geäußert wird. Maintainer konzentrieren sich in der Regel auf die Codequalität.
• Wenn Änderungen für deinen Pull Request angefordert werden, öffne keinen neuen Pull Request, um die Änderungen anzugehen. Wenn du den vorhandenen Pull Request geöffnet lässt und Änderungen vornimmst, kannst du verhindern, dass die Maintainer den Kontext verlieren.
• Wenn dein Pull Request wochenlang unbearbeitet bleibt, schreibe einen höflichen Kommentar, um um Feedback zu bitten. Erwähne die Handles von Maintainern nicht direkt. Maintainer machen die Open-Source-Arbeit häufig neben einer Vollzeitbeschäftigung. Wenn du Verständnis für ihre eingeschränkte Verfügbarkeit zeigst, fördert das die Zusammenarbeit.
• Wenn dein Beitrag nicht akzeptiert wird, bitte die Maintainer um Feedback, damit du diesen Kontext für das nächste Mal hast, wenn du einen Beitrag leisten möchtest.

Nächste Schritte

Du weißt nun, wie du die Issues erkennst, an denen du arbeiten kannst, Beiträge erstellst, die Maintainer zu mergen bereit sind, und wie der Pull-Request-Reviewvorgang abläuft. Die Open-Source-Community auf GitHub ist bereit für deine einzigartigen Perspektive und Fähigkeiten. Suche ein neues Projekt, das dich begeistert, finde ein Issue, an dem du arbeiten kannst, und beginnen mit deinem Beitrag.