Wenn Sie zu einem Projekt beitragen, benötigen Sie einen sicheren Ort, um Code zu schreiben und zu verfeinern, bevor es sich auf Ihre Hauptcodebasis auswirkt. Branches, Forks, Commits und Pull Requests wirken zusammen, um Ihnen diesen Freiraum zu geben, sodass Sie experimentieren, Arbeit schrittweise einchecken und abgeschlossene Änderungen zur Überprüfung vorschlagen können.
Ihre Arbeit mit Branches und Forks isolieren
Die meisten Arbeiten beginnen mit der Erstellung einer isolierten Kopie des Codes, die Sie frei ändern können.
- Verwenden Sie einen Branch, wenn Sie Schreibzugriff auf ein Repository haben. Mit einer Verzweigung können Sie ein Feature entwickeln, einen Fehler beheben oder in einem enthaltenen Bereich des Repositorys experimentieren, ohne dass sich dies auf andere Verzweigungen auswirkt. Sie erstellen eine Verzweigung aus einer vorhandenen Verzweigung, in der Regel die Standardverzweigung.
- Verwenden Sie einen Fork, wenn Sie keinen Schreibzugriff haben oder wenn Sie vollständige Unabhängigkeit vom ursprünglichen Projekt wünschen. Ein Fork ist ein separates Repository, das Code und Sichtbarkeitseinstellungen mit dem ursprünglichen „upstream“-Repository teilt. Es verfügt über eigene Verzweigungen, Probleme und Pullanforderungen. Mit einem Fork können Sie auch Pull Requests für das Upstream-Repository öffnen.
Ein Branch ist in der Regel die einfachste Wahl, wenn Sie bereits in einem gemeinsamen Repository zusammenarbeiten. Ein Fork ist häufig die beste Wahl für Open-Source-Beiträge, wenn Sie möglicherweise keinen Schreibzugriff auf das Upstream-Repository haben.
Arbeit mit Commits einchecken
Beim Schreiben von Code speichern Sie kleine, aussagekräftige Gruppen von Änderungen als Commits. Jeder Commit zeichnet eine Momentaufnahme Ihrer Arbeit zusammen mit einer Nachricht auf, die beschreibt, was geändert wurde, wodurch das Nachverfolgen des Verlaufs, überprüfen von Änderungen und das Verständnis der Entwicklung des Codes erleichtert wird.
Wenn Sie in Ihrem Branch oder Fork häufig committen, ermöglicht Ihnen das Folgendes:
- Unterteilen Sie eine größere Änderung in bearbeitbare Schritte.
- Führen Sie einen Rollback in einen früheren Zustand durch, wenn ein Experiment nicht funktioniert.
- Geben Sie Prüfern eine klare Nachverfolgung darüber, wie Sie zur endgültigen Änderung gekommen sind.
Vorschlagen von Änderungen mit Pullanforderungen
Wenn Ihre Arbeit zum Teilen bereit ist, öffnen Sie einen Pull Request, um vorzuschlagen, Ihre Änderungen in den Basis-Branch zusammenzuführen. Ein Pull Request führt Ihre Commits, eine Beschreibung der Änderung und die Werkzeuge zusammen, die Reviewer benötigen, um ihn vor dem Merge zu besprechen und zu prüfen.
Sie können eine Pull-Anforderung öffnen, während die Arbeit noch ausgeführt wird, indem Sie eine Pull-Entwurfsanforderung erstellen, die Ihre Änderungen freigibt, ohne eine formale Überprüfung anzufordern. Dies ist nützlich, wenn Sie frühzeitig feedback möchten oder automatisierte Prüfungen mit Ihrem Code ausführen möchten.
Ihren Code aktuell und optimiert halten
Während eine Pullanforderung geöffnet ist, kann sich der Basiszweig weiter ändern, wenn andere Personen ihre Arbeit zusammenführen. Um Ihre Änderungen sauber zu halten und Konflikte zu reduzieren, können Sie:
- Mergen Sie den Basis-Branch regelmäßig in Ihren Branch oder rebasen Sie ihn darauf, damit Ihr Diff auf das fokussiert bleibt, was Ihre Änderung einführt. GitHub zeigt standardmäßig einen Drei-Punkt-Diff an, der deinen Branch mit dem Punkt vergleicht, an dem er sich vom Basis-Branch getrennt hat.
- Mit Rebase kannst du eine unübersichtliche Commit-Historie aufräumen — indem du Commits neu anordnest, zusammenfasst oder umformulierst —, bevor du sie zur Überprüfung vorlegst.
- Lösen Sie Zusammenführungskonflikte, wenn Git konkurrierende Änderungen nicht automatisch kombinieren kann.
Arbeiten mit Repository-Steuerelementen
Erfahrene Mitwirkende arbeiten innerhalb der Leitplanken, die von einem Repository vorgegeben werden. Diese Steuerelemente bestimmen, wohin Sie pushen können, wer Ihre Arbeit genehmigen muss und welche Prüfungen erfolgreich sein müssen, bevor sie zusammengeführt werden kann.
- Geschützte Branches und Regelsätze können direkte Pushes auf wichtige Branches blockieren, eine lineare Historie oder signierte Commits erfordern und Statusprüfungen oder Reviews vor dem Mergen voraussetzen.
- Codeverantwortliche werden automatisch um eine Überprüfung gebeten, wenn Ihre Änderung Dateien ändert, für die sie verantwortlich sind. Planen Sie ihre Freigabe also für sensible Bereiche ein.
- Push-Regelsätze können für ein Fork-Netzwerk gelten und Dateipfade, -größen oder -namen in jedem Fork einschränken.
- Pre-Receive-Hooks ermöglichen es Administratoren auf GitHub Enterprise Server, Richtlinienprüfungen auf dem Server durchzusetzen, bevor Commits akzeptiert werden.
Integrierte Toolkette
Pullanforderungen verbinden Ihren Code mit den Automatisierungs- und Diensten, mit denen Sie Code schnell und sicher schreiben können.
GitHub Copilot ** kann Ihnen beim Schreiben, Debuggen und Optimieren von Code helfen.
- Code scanning und Dependabot decken Sicherheitsprobleme und verwundbare Abhängigkeiten auf, wenn Ihre Änderungen einen Pull Request durchlaufen, sodass Sie frühzeitig sichere Programmierverfahren anwenden können.
- GitHub Actions kann eine kontinuierliche Integration auf jedem Push an Ihre Pull-Anforderung ausführen, ihre Änderungen automatisch erstellen und testen.