Skip to main content

Diese Version von GitHub Enterprise Server wird eingestellt am 2026-03-17. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Beitrag zu open source

Erfahren Sie, wie Sie einen Beitrag zu einem open source Projekt leisten, das von Betreuern akzeptiert wird.

In diesem Artikel erfahren Sie, wie Sie zu einem open source Projekt beitragen, indem Sie ein Beispiel durcharbeiten. 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:** Die Strukturierung deines Pull Requests, einzuschließende Informationen und zu erfüllende Überprüfungserwartungen.
    
  •         **Entwicklungssetup:** Einrichten der lokalen Entwicklungsumgebung, der erforderlichen Abhängigkeiten und der 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.
    
  •         **Beitrag leisten:** Stellt Richtlinien und Anweisungen für Projektmitwirkende zur Verfügung. 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 Problem 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. Klicken Sie oben rechts auf einer Seite in GitHub auf die Schaltfläche neben der Suchleiste.

    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.

Tipp

Wenn du jemals an einem Issue ohne die help wanted- oder good first issue-Bezeichnung arbeitest, solltest du die Maintainer des Issues fragen, ob du einen Pull Request öffnen darfst, um zu bestätigen, dass dein geplanter Beitrag den Zielen des Projekts entspricht.

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. Navigieren Sie zu dem Projekt GitHub Docs unter https://github.com/github/docs.

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

  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 Fork-Szenarien, wie z. B. bei Beiträgen zu Open-Source-Projekten, genügt es oft, den Standardbranch zu 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. Gehe auf GitHub zu deinem Fork des github/docs-Repository.

  2. Klicke oberhalb der Liste der Dateien auf Code.

    Screenshot: Liste der Dateien auf der Startseite eines Repositorys. Die Schaltfläche „Code“ ist orange umrandet.

  3. Kopiere die URL für das Repository.

    • Um das Repository mit HTTPS zu klonen, klicken Sie 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 .

      Screenshot des Dropdownmenüs „Code“ Rechts neben der HTTPS-URL für das Repository ist ein Kopiersymbol dunkelorange umrandet.

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

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

  6. Geben Sie ein git clone, und fügen Sie dann die URL ein, die Sie zuvor kopiert haben. 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 Themenzweig

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.

Shell
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 Ihr Beitrag zusammengeführt 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 einem einzelnen Commit, aber halte nicht zusammengehörige Änderungen in separaten Commits.

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

Bemühe dich, die Beschreibungen der Commits 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.

Shell
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. Gehen Sie zu Ihrem geforkten Repository auf GitHub. Beispiel: https://github.com/YOUR-USERNAME/docs.
  2. Du solltest einen Prompt zum „Vergleichen von & Pull-Requests" für deinen kürzlich gepushten Branch sehen. Klicken Sie darauf.
  3. Wenn nicht, wechsle zur Registerkarte „Pull-Requests“ und klicke auf „Neue Pull-Anfrage“.
  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 Vergleichs-Branch 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.

Tipp

Vermeide das erzwungene Pushen, sobald ein Pull Request zur Überprüfung übermittelt wurde. Dadurch wird es für Maintainer schwieriger zu erkennen, dass du ihr Feedback adressierst.

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. Betreuer gleichen häufig Open-Source-Arbeit mit Vollzeitaufgaben aus, und das Verständnis ihrer Zeiteinschränkungen fördert eine bessere 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 zu GitHub ist bereit für Ihre einzigartige Perspektive und Fähigkeiten. Suche ein neues Projekt, das dich begeistert, finde ein Issue, an dem du arbeiten kannst, und beginnen mit deinem Beitrag.