„Ich lade es von GitHub herunter“ und „Ich muss GitHub lernen“ sind typische Sätze, die mehrere unterschiedliche Dinge meinen können. Vielleicht suchen Sie eine fertige Installationsdatei, vielleicht laden Sie nur den Quellcode eines Projekts herunter. Und beim Lernen kann es um Git-Befehle, die GitHub-Webseite oder den Ablauf einer Mitarbeit an einem fremden Projekt gehen.
GitHub ist eine Online-Plattform zum Speichern, Verwalten und gemeinsamen Bearbeiten von Git-Repositories sowie zur Organisation von Softwareprojekten. Git ist dagegen das Versionsverwaltungssystem, das Änderungen an Dateien aufzeichnet und ihre Historie verwaltet. Kurz gefasst: Git ist das Werkzeug, GitHub ist ein Hosting- und Kollaborationsdienst für Git-Projekte.
Ein einzelnes Repository auf GitHub kann ein fertiges Programm enthalten, muss es aber nicht. Ebenso möglich sind eine Programmbibliothek, Dokumentation, Konfigurationsdateien, Skripte, Forschungsdaten, Lernmaterial oder ein unfertiger Prototyp. Bevor Sie auf eine Download-Schaltfläche klicken, sollten Sie deshalb klären, was das Projekt bereitstellt, welchen Entwicklungsstand Sie betrachten und welche Voraussetzungen für die Nutzung gelten.
GitHub erweitert die reine Versionsverwaltung um Projektkommunikation, Codeprüfung, Veröffentlichungen, Automatisierung, Berechtigungen und öffentliche Sichtbarkeit. Diese Funktionen erleichtern Zusammenarbeit, sind aber weder ein Qualitätssiegel noch eine Garantie dafür, dass veröffentlichte Software sicher, aktuell oder für Ihr System geeignet ist.
GitHub und Git trennen: Plattform, Werkzeug und Repository
Die Begriffe hängen eng zusammen, bezeichnen aber verschiedene Ebenen. Git verwaltet Versionen eines Projekts. Ein Repository enthält die Dateien und deren Historie. GitHub speichert solche Repositories online und legt zusätzliche Arbeits- und Kommunikationsfunktionen darum. Diese Trennung erklärt, warum Sie ein öffentliches Projekt im Browser betrachten oder als ZIP-Datei laden können, ohne Git installiert zu haben.
Git verwaltet Änderungen auch ohne GitHub
Git ist ein verteiltes Versionsverwaltungssystem. Es zeichnet Änderungen an Dateien auf, speichert nachvollziehbare Projektstände und ermöglicht parallele Entwicklung. Eine lokale Git-Kopie kann die vollständige Historie eines Repositorys enthalten. Dadurch lassen sich Änderungen auch ohne ständige Verbindung zu GitHub untersuchen, speichern und miteinander vergleichen.
Git ist nicht an GitHub gebunden. Sie können ein Repository ausschließlich auf dem eigenen Rechner verwenden, auf einem selbst betriebenen Server ablegen oder über einen anderen Hostingdienst teilen. Fällt GitHub aus oder wird ein Projekt dorthin nicht hochgeladen, funktioniert Git als Versionsverwaltung weiterhin. GitHub ersetzt Git daher nicht, sondern stellt eine Plattform für gehostete Git-Repositories und darauf aufbauende Abläufe bereit.
Für einen bloßen Download öffentlicher Dateien benötigen Sie Git nicht. Möchten Sie dagegen die Historie untersuchen, eigene Änderungen sauber verfolgen oder regelmäßig mit dem Online-Repository synchronisieren, ist eine über Git erstellte lokale Kopie zweckmäßiger als ein ZIP-Archiv.
Ein Repository ist mehr als ein Ordner mit Programmdateien
Ein Repository – häufig kurz „Repo“ genannt – umfasst Projektdateien und ihre Versionshistorie. Darin können Quellcode, Dokumentation, Skripte, Konfigurationen, Bilder, Beispieldateien, Testdaten, kompilierte Binärdateien oder Vorlagen liegen. Auch ein Buch, eine Webseite, technische Spezifikationen oder ein Datenauswertungsprojekt lassen sich mit Git verwalten.
Der sichtbare Dateibaum sagt deshalb noch nicht, wie Sie das Projekt verwenden. Dateien mit Endungen einer Programmiersprache deuten auf Quellcode hin, sind aber keine Installationsanleitung. Manche Projekte werden erst mit einem Compiler oder Build-System in ein ausführbares Programm übersetzt. Andere sind Bibliotheken, die Entwickler in eigene Software einbinden. Wieder andere liefern nur Konfigurationsbeispiele oder Skripte für eine bestimmte Serverumgebung.
Ein Commit speichert einen nachvollziehbaren Änderungsschritt in der Projektgeschichte. Er verknüpft einen Projektzustand typischerweise mit einer Beschreibung, einem Zeitpunkt und Angaben zum Urheber beziehungsweise Einreicher. Die Commit-Historie zeigt, welche Dateien verändert wurden und wie sich das Projekt entwickelt hat. Eine umfangreiche Historie belegt jedoch nicht automatisch, dass jede Änderung geprüft oder fachlich korrekt ist.
Ein Branch ist eine Entwicklungslinie innerhalb des Repositorys. Der Standard-Branch enthält häufig den zentralen Projektstand, während weitere Branches neue Funktionen, Reparaturen oder Experimente aufnehmen. Wenn Sie einen bestimmten Branch auswählen und anschließend „Download ZIP“ verwenden, erhalten Sie den Dateistand dieses Branches – nicht zwingend die letzte veröffentlichte oder stabile Programmversion.
Tags markieren häufig bestimmte Punkte in der Historie, etwa eine Versionsnummer. Ein Tag, ein Release und ein Branch sind dennoch nicht dasselbe: Der Branch kann sich weiterbewegen, der Tag verweist auf einen bestimmten Stand, und ein GitHub-Release ergänzt einen solchen markierten Stand um Veröffentlichungsinformationen und gegebenenfalls separate Download-Dateien.
GitHub organisiert Zusammenarbeit über die Git-Historie hinaus
GitHub hostet die Git-Daten, ergänzt sie aber um Funktionen, die nicht zum Kern von Git gehören. Issues erfassen Aufgaben, Fehlerberichte und Ideen. Pull Requests machen vorgeschlagene Änderungen prüfbar. Actions automatisieren beispielsweise Tests, Builds oder Veröffentlichungen. Releases bündeln veröffentlichte Projektstände. Berechtigungen regeln, wer lesen, schreiben, prüfen oder verwalten darf.
Öffentliche Repositories sind grundsätzlich über das Internet einsehbar. Private Repositories beschränken den Zugriff auf berechtigte Personen. In bestimmten Unternehmensumgebungen kann zusätzlich eine interne Sichtbarkeit existieren. Diese Sichtbarkeitseinstellungen beschreiben zunächst nur, wer auf das Repository zugreifen kann. Sie sagen nichts darüber aus, ob das Projekt offiziell, sicher, ausgereift oder rechtlich frei nutzbar ist.
Nicht jedes Repository nutzt alle GitHub-Funktionen. Releases, Issues, Discussions, Wiki oder Actions können fehlen oder deaktiviert sein. Ein fehlender Bereich ist daher nicht zwingend ein Bedienfehler. Manche Projektteams dokumentieren auf einer externen Webseite, verwalten Fehler in einem anderen System oder veröffentlichen fertige Pakete über einen Paketmanager statt über GitHub-Releases.
Für Einsteiger ist deshalb nicht die Anzahl sichtbarer Funktionen entscheidend, sondern die Zuordnung zum eigenen Ziel: Möchten Sie das Projekt verstehen, eine fertige Version installieren, Dateien bearbeiten, einen Fehler melden oder eine Änderung beitragen? Erst diese Frage bestimmt den passenden Bereich und die richtige Art des Downloads.
Ein GitHub-Repository lesen: Code, Releases und Projektkommunikation
Die Repository-Seite ist kein einheitlicher Downloadbereich, sondern eine Arbeitsoberfläche. README, Dateibaum, Releases, Issues und Pull Requests beantworten unterschiedliche Fragen. Die folgende Zuordnung verhindert insbesondere, dass Sie Quellcode mit einer fertigen Anwendung, einen Fork mit einem lokalen Download oder einen Pull Request mit einer Dateiübertragung verwechseln.
Welcher GitHub-Bereich führt zu welchem Ergebnis?
| Ihr Ziel | Passender GitHub-Bereich | Was Sie tatsächlich erhalten oder tun | Voraussetzung | Typische Fehlannahme |
|---|---|---|---|---|
| Projekt verstehen | README und Codebereich | Sie lesen Zweck, Voraussetzungen und Dateistruktur und prüfen anschließend die relevanten Projektdateien. | README und Dokumentation müssen vorhanden und ausreichend aktuell sein. | Der sichtbare Dateibaum sei bereits eine Installationsanleitung. |
| Fertige Version beziehen | Releases | Sie wählen Release Notes und ein passendes Asset, etwa einen Installer, ein Paket oder eine Binärdatei. | Das Projekt muss fertige Assets für Ihr Betriebssystem und Ihre Architektur veröffentlichen. | „Source code“ sei automatisch die fertige Anwendung. |
| Dateischnappschuss speichern | Code und Download ZIP | Sie erhalten die Dateien des ausgewählten Branches, Tags oder Commits ohne vollständige Git-Historie. | Sie benötigen keine laufende Synchronisierung und keine Git-Arbeit. | Das ZIP enthalte immer die stabile Programmversion oder einen Installer. |
| Vollständig lokal mit Git arbeiten | Clone | Sie erstellen eine lokale Git-Kopie einschließlich Repository-Daten und Historie. | Git oder eine geeignete Git-Oberfläche muss eingerichtet sein; bei privaten Projekten benötigen Sie Zugriff. | Clone und ZIP-Download lieferten dasselbe. |
| Bestimmten Entwicklungsstand prüfen | Branch, Tag oder Commit | Sie wählen eine Entwicklungslinie, eine Markierung oder einen exakt identifizierten Projektstand. | Sie müssen wissen, welcher Stand dokumentiert oder in einer Anleitung verlangt wird. | Der Standard-Branch entspreche stets der neuesten stabilen Veröffentlichung. |
| Fehler oder Wunsch melden | Issues | Sie erstellen einen nachvollziehbaren Bericht oder beteiligen sich an einer bestehenden Projektaufgabe. | Issues müssen aktiviert sein; Vorlagen und Projektregeln sind zu beachten. | Ein Issue garantiere Support, Fehlerbestätigung oder Umsetzung. |
| Änderung zur Übernahme vorschlagen | Pull Request | Sie stellen Änderungen aus einem Branch oder Fork zur Diskussion und Prüfung bereit. | Es müssen Commits mit einer vergleichbaren Ausgangs- und Zielentwicklungslinie existieren. | Ein Pull Request lade Dateien herunter oder werde automatisch übernommen. |
| Eigenes Experiment auf GitHub führen | Fork | Sie erzeugen ein separates, mit dem Ursprungsprojekt verbundenes Repository in einem zulässigen Konto oder einer Organisation. | Forking muss für das Projekt und Ihr Konto erlaubt sein. | Ein Fork sei nur ein Branch oder bereits eine lokale Kopie. |
| Projekt später wiederfinden | Star | Sie merken das Repository in Ihrem GitHub-Konto vor und signalisieren Interesse. | Sie benötigen ein GitHub-Konto. | Viele Stars bestätigten Sicherheit, Aktualität oder technische Qualität. |
| Änderungen verfolgen | Watch | Sie abonnieren Benachrichtigungen für alle oder ausgewählte Ereignisarten. | Die Benachrichtigungseinstellungen müssen zu Ihrem Informationsbedarf passen. | Watch sei nur ein öffentliches Lesezeichen wie Star. |
| Automatisierte Prüfungen nachvollziehen | Actions | Sie betrachten ausgeführte Workflows, etwa Tests, Builds oder Deployments, sofern Sie Zugriff darauf haben. | Das Repository muss entsprechende Workflows verwenden und deren Ergebnisse zugänglich machen. | Ein grüner Workflow beweise vollständige Fehlerfreiheit und Sicherheit. |
| Fragen oder offene Themen diskutieren | Discussions oder Wiki | Sie nutzen Community-Gespräche beziehungsweise ausführlichere Projektdokumentation. | Der jeweilige Bereich muss aktiviert und vom Projekt gepflegt sein. | Jedes Repository besitze automatisch ein Wiki und ein Supportforum. |
Prüfen Sie insbesondere vor einem Download, ob die Projektverantwortlichen eine bestimmte Bezugsart nennen. Ein Projekt kann Releases auf GitHub anbieten, fertige Pakete aber ebenso über einen App-Store, eine Herstellerseite, einen Paketmanager oder ein Container-Repository verteilen. Der sichtbare GitHub-Download ist nicht automatisch der vom Projekt vorgesehene Installationsweg.
README und Codebereich zuerst auf Zweck und Voraussetzungen prüfen
Die README ist häufig der beste Einstieg in ein Repository. Sie beschreibt typischerweise, was das Projekt leistet, für wen es bestimmt ist, wie die ersten Schritte aussehen, wo Hilfe verfügbar ist und wer das Projekt betreut. Sie kann außerdem auf Installationsanleitungen, Beispiele, Lizenzbedingungen, Sicherheitsrichtlinien und Beitragsregeln verweisen.
Eine README ist jedoch eine vom Projekt gepflegte Datei und keine von GitHub geprüfte Gebrauchsanleitung. Kontrollieren Sie, ob die Angaben zum gewählten Branch oder Release passen. Ein Installationsbefehl kann nur für bestimmte Betriebssysteme, Prozessorarchitekturen, Laufzeitversionen oder Paketmanager gelten. Fehlen eindeutige Voraussetzungen, sollten Sie nicht aus einzelnen Dateinamen improvisieren.
Der Codebereich zeigt die Dateien des aktuell ausgewählten Entwicklungsstands. Achten Sie auf den Branch-Namen und auf Verzeichnisse für Dokumentation, Beispiele, Tests oder Build-Konfigurationen. Dateien wie eine CONTRIBUTING-Anleitung richten sich an Mitwirkende; eine Sicherheitsrichtlinie erklärt häufig den vorgesehenen Meldeweg für Schwachstellen. Ein Lizenztext regelt, in welchem Umfang Sie den Inhalt verwenden, verändern oder weitergeben dürfen.
Die Commit-Historie hilft bei der Einordnung: Sie zeigt letzte Änderungen, betroffene Dateien und Beschreibungen der Änderungsschritte. Lange Inaktivität kann bei sicherheitskritischer oder stark umgebungsabhängiger Software ein Warnzeichen sein, ist aber kein automatischer Mangel. Ein abgeschlossenes Werkzeug kann seltene Aktualisierungen benötigen, während ein aktives Projekt trotz täglicher Commits instabil sein kann.
Releases können fertige Software enthalten – Quellcodearchive meist nicht
Mit einem GitHub-Release können Projektverantwortliche einen markierten Projektstand veröffentlichen. Dazu gehören meist ein Titel, Versionsangaben und Release Notes mit Neuerungen, Fehlerkorrekturen, bekannten Problemen oder Hinweisen zur Aktualisierung. Zusätzlich lassen sich Assets anhängen, beispielsweise Installationsprogramme, portable Anwendungen, Pakete, Firmwaredateien oder Prüfsummen.
GitHub ergänzt bei einem Release automatisch Quellcodearchive für den zugehörigen Tag. Einträge wie Source code (zip) oder Source code (tar.gz) enthalten daher einen Schnappschuss der Repository-Dateien. Sie sind nicht automatisch ausführbar und nicht mit zusätzlich hochgeladenen Installern oder Binärdateien gleichzusetzen. Benötigt das Projekt einen Build, müssen Sie die dafür dokumentierten Werkzeuge und Abhängigkeiten selbst bereitstellen.
Lesen Sie die Dateinamen und Release Notes, bevor Sie ein Asset wählen. Betriebssystem, Prozessorarchitektur, Paketformat und erforderliche Laufzeit müssen zusammenpassen. Eine Datei für Linux auf ARM-Prozessoren hilft beispielsweise nicht automatisch auf einem Windows-PC mit x86-64-Prozessor. Auch die Kennzeichnung als „Latest“ bedeutet nicht zwingend, dass die Veröffentlichung für jeden Einsatzzweck die richtige ist: Vorabversionen, ältere unterstützte Produktlinien oder plattformspezifische Ausgaben können andere Entscheidungen erfordern.
Bietet ein Projekt keine Releases an, folgt daraus nicht, dass etwas fehlt. Bibliotheken werden häufig über Paketmanager verteilt, Webseiten direkt bereitgestellt und reine Dokumentationsprojekte gar nicht installiert. Umgekehrt beweist ein vorhandenes Release nicht, dass dessen Assets geprüft, signiert oder für Endnutzer vorgesehen sind.
Issues und Pull Requests erfüllen unterschiedliche Aufgaben
Issues erfassen Fehler, Ideen und Arbeitsaufgaben
Ein Issue kann einen Fehlerbericht, einen Funktionswunsch, eine Frage, eine Aufgabe oder eine Planungsnotiz enthalten. Projektteams können Issues mit Labels, Zuständigkeiten, Meilensteinen und weiteren Metadaten ordnen. Vor einem neuen Eintrag sollten Sie bestehende Issues durchsuchen, Vorlagen beachten und die notwendigen Angaben liefern: betroffene Version, Betriebssystem, nachvollziehbare Schritte, erwartetes Verhalten und tatsächliches Ergebnis.
Ein offenes Issue ist kein bestätigter Programmfehler. Ebenso wenig entsteht daraus ein Anspruch auf Antwort oder Umsetzung. Die Projektverantwortlichen können einen Bericht als Duplikat schließen, weitere Informationen verlangen oder feststellen, dass das Verhalten beabsichtigt ist. Für allgemeine Fragen und offene Gespräche nutzen einige Projekte stattdessen Discussions oder externe Community-Kanäle.
Pull Requests schlagen konkrete Änderungen zur Übernahme vor
Ein Pull Request schlägt vor, Änderungen aus einem Branch oder Fork in einen anderen Branch zu übernehmen. Die Seite bündelt Beschreibung, Kommentare, Commits, Unterschiede zwischen Dateien, Reviews und automatisierte Prüfungen. Projektverantwortliche können einzelne Zeilen kommentieren, Änderungen anfordern, den Vorschlag ablehnen oder ihn nach erfolgreicher Prüfung zusammenführen.
Der Begriff „Pull“ führt bei Einsteigern leicht in die falsche Richtung. Ein Pull Request holt keine Software auf Ihren Rechner. Er ist ein kollaborativer Änderungsvorschlag auf GitHub. Auch eine vollständig ausgearbeitete Änderung wird nicht automatisch übernommen: Beitragsregeln, technische Prüfungen, Reviews und die Entscheidung der Projektverantwortlichen bestimmen den weiteren Verlauf.
Actions, Wiki, Discussions, Star und Watch richtig einordnen
GitHub Actions führt konfigurierbare Automatisierungsabläufe aus. Ein Workflow kann beispielsweise bei einem neuen Commit Tests starten, aus Quellcode ein Paket bauen, ein Release veröffentlichen oder eine Anwendung ausrollen. Die Workflow-Dateien gehören zum Repository und können durch Ereignisse, Zeitpläne oder manuell ausgelöst werden. Ein erfolgreicher Lauf bestätigt nur die Prüfungen, die tatsächlich konfiguriert und ausgeführt wurden.
Ein Wiki kann längere Projektdokumentation aufnehmen. Discussions eignen sich unter anderem für Fragen, Antworten, Ankündigungen und offene Community-Gespräche. Beide Bereiche sind optional. Fehlen sie, suchen Sie in der README nach einer externen Dokumentation, einem Forum oder anderen Kontaktwegen.
Mit einem Star merken Sie ein interessantes Repository vor und zeigen Anerkennung. Mit Watch abonnieren Sie dagegen Benachrichtigungen. Je nach Einstellung können diese beispielsweise Issues, Pull Requests, Releases, Sicherheitsmeldungen oder Discussions betreffen. Hohe Star-Zahlen sind ein Popularitätsindikator, aber kein belastbarer Nachweis für Sicherheit, Wartungsqualität oder Eignung.
GitHub sicher nutzen und zu fremden Projekten beitragen
Öffentlich sichtbarer Code ist leicht erreichbar, aber weder automatisch offiziell noch geprüft. Vor dem Ausführen müssen Sie Herkunft, Zweck, Veröffentlichungsform und technische Voraussetzungen bewerten. Für eigene Beiträge ist zusätzlich zu klären, ob Sie direkt schreiben dürfen oder über Fork, Branch, Commit und Pull Request arbeiten.
Öffentlich und privat beschreiben Zugriff, nicht Sicherheit
Ein öffentliches Repository ist für alle im Internet zugänglich. Daraus folgt nicht, dass GitHub das Projekt geprüft oder einem bekannten Hersteller zugeordnet hat. Namen und Profilbilder lassen sich nachahmen. Prüfen Sie bei wichtigen Downloads, ob die offizielle Projekt- oder Herstellerseite auf genau dieses Konto und Repository verweist.
Öffentlich bedeutet außerdem nicht automatisch Open Source. Erst eine passende Lizenz legt fest, ob und unter welchen Bedingungen Sie Code verwenden, verändern und weitergeben dürfen. Fehlt eine Lizenz, bleibt der Inhalt zwar technisch sichtbar, die üblichen urheberrechtlichen Beschränkungen gelten aber weiterhin. Ein Fork auf GitHub ist keine pauschale Erlaubnis für jede Nutzung außerhalb der Plattform.
Ein privates Repository beschränkt den Zugriff, ist aber kein geeigneter Ersatz für ein Geheimnis- oder Kundendatensystem. Tokens, API-Schlüssel, Passwörter und andere Zugangsdaten gehören nicht als Klartext in Projektdateien. Auch private Repositories können durch falsche Berechtigungen, kompromittierte Konten oder spätere Sichtbarkeitsänderungen offengelegt werden. Verwenden Sie vorgesehene Secret-Speicher und vergeben Sie nur notwendige Rechte.
Code und Skripte vor der Ausführung in mehreren Schritten prüfen
Ein Skript aus einem Repository kann nützlich, aber auch veraltet, experimentell, manipuliert oder für eine andere Umgebung geschrieben sein. Besonders Befehle mit Administrator- beziehungsweise Root-Rechten können Dateien verändern, Programme nachladen, Sicherheitsfunktionen abschalten oder Zugangsdaten auslesen. Führen Sie unbekannten Code nicht allein deshalb aus, weil er auf GitHub liegt.
- Eigentümer klären: Prüfen Sie die Verknüpfung von einer offiziellen Projektseite und verlassen Sie sich nicht nur auf einen bekannten Repository-Namen.
- Zweck lesen: Kontrollieren Sie README, Dokumentation und Release Notes, bevor Sie Dateien laden oder Befehle übernehmen.
- Entwicklungsstand einordnen: Prüfen Sie Branch, Tag, Versionsnummer, letzte Aktivität und Hinweise auf Vorab- oder Testversionen.
- Probleme recherchieren: Suchen Sie in Issues und Sicherheitsmeldungen nach bekannten Fehlern, unbehobenen Schwachstellen oder Kompatibilitätsproblemen.
- Lizenz kontrollieren: Klären Sie, ob die vorgesehene Nutzung, Veränderung und Weitergabe rechtlich erlaubt ist.
- Zielumgebung abgleichen: Prüfen Sie Betriebssystem, Architektur, Laufzeit, benötigte Rechte, Build-Werkzeuge und Konfiguration.
- Abhängigkeiten bewerten: Auch vertrauenswürdiger Hauptcode kann veraltete oder manipulierte Bibliotheken und Installationsskripte nachladen.
- Integritätssignale nutzen: Vergleichen Sie vorhandene Prüfsummen, Signaturen oder Attestierungen und bevorzugen Sie nachvollziehbar veröffentlichte Assets.
GitHub kann kryptografisch signierte Commits und Tags als verifiziert kennzeichnen. Projekte können außerdem Prüfsummen, Artifact Attestations oder unveränderliche Releases verwenden. Solche Verfahren erhöhen die Nachvollziehbarkeit von Herkunft und Integrität. Sie beweisen jedoch nicht, dass der signierte Code fachlich richtig, frei von Schwachstellen oder für Ihren Rechner ungefährlich ist.
Auch grüne Actions-Prüfungen haben eine begrenzte Aussage. Ein Workflow kann umfangreiche Tests durchführen oder lediglich eine kleine Formatprüfung. Entscheidend ist, welche Prüfungen eingerichtet sind und für welchen Commit beziehungsweise welches Release sie liefen. Bei unklaren Projekten sollten Sie unbekannte Software zunächst in einer isolierten Testumgebung untersuchen und weitreichende Rechte vermeiden.
Fork, Branch, Commit und Pull Request sauber voneinander trennen
Bei einem fremden Repository besitzen Sie normalerweise keinen direkten Schreibzugriff. Ein typischer Beitragsablauf verwendet deshalb mehrere klar getrennte Objekte: Der Fork ist Ihr eigenes, mit dem Ursprungsprojekt verbundenes Repository auf GitHub. Ein Branch ist darin die isolierte Entwicklungslinie. Commits speichern Ihre Änderungsschritte. Der Pull Request schlägt anschließend die Übernahme dieser Änderungen in den gewünschten Branch des Ursprungsprojekts vor.
- Lesen Sie README, CONTRIBUTING-Datei, Verhaltensregeln und vorhandene Vorlagen. Prüfen Sie, ob das Projekt Beiträge annimmt und ob zu Ihrer Änderung bereits ein Issue oder Pull Request existiert.
- Erstellen Sie einen Fork, falls Sie keinen Schreibzugriff auf das Ursprungsrepository besitzen und das Forken erlaubt ist.
- Klonen Sie den Fork für lokale Arbeit und richten Sie bei Bedarf das Ursprungsrepository als Upstream-Quelle ein.
- Synchronisieren Sie Ihren Fork mit dem aktuellen Zielstand, damit Ihre Änderung nicht auf einer überholten Grundlage beginnt.
- Legen Sie einen eigenen Arbeits-Branch an, statt Änderungen unkontrolliert im zentralen Branch Ihres Forks zu sammeln.
- Speichern Sie logisch zusammengehörige Änderungen in nachvollziehbaren Commits und führen Sie die vom Projekt verlangten Tests oder Prüfungen aus.
- Übertragen Sie den Arbeits-Branch zu Ihrem Fork und öffnen Sie einen Pull Request gegen den korrekten Zielbranch des Ursprungsprojekts.
- Reagieren Sie auf Reviews und fehlgeschlagene Checks. Weitere Commits im selben Arbeits-Branch aktualisieren den Pull Request üblicherweise, bis er zusammengeführt oder geschlossen wird.
Ein Fork bleibt nicht automatisch dauerhaft mit allen neuen Änderungen des Upstream-Repositorys synchron. Vor neuer Arbeit sollten Sie deshalb den vorgesehenen Zielbranch abgleichen. Andernfalls entstehen unnötige Konflikte oder Sie schlagen eine Änderung vor, die im Ursprungsprojekt längst anders gelöst wurde.
Typische GitHub-Fehler erkennen und gezielt korrigieren
- Falscher Branch heruntergeladen: Prüfen Sie Branch, Tag oder verlangte Commit-ID und laden Sie den dokumentierten Stand erneut.
- Quellcode statt Release verwendet: Suchen Sie nach einem plattformspezifischen Release-Asset oder folgen Sie der dokumentierten Build-Anleitung.
- Build-Anleitung fehlt: Raten Sie keine Befehle. Prüfen Sie Dokumentation, CONTRIBUTING-Datei und den vorgesehenen Bezugsweg oder fragen Sie über den vom Projekt genannten Kanal nach.
- Abhängigkeiten nicht installiert: Gleichen Sie Laufzeiten, Bibliotheken, Compiler, Paketmanager und erforderliche Versionen mit der Projektdokumentation ab.
- Token öffentlich committed: Behandeln Sie ihn als kompromittiert und widerrufen oder rotieren Sie ihn sofort. Das Löschen aus der aktuellen Datei genügt nicht, weil der Wert in der Historie verbleiben kann.
- Pull Request falsch verstanden: Betrachten Sie ihn als Vorschlag zur Zusammenführung von Änderungen, nicht als Download, Supportticket oder automatische Freigabe.
- Fork nicht aktualisiert: Synchronisieren Sie ihn mit dem Upstream-Zielbranch und lösen Sie mögliche Konflikte, bevor Sie weitere Änderungen einreichen.
Häufige Fragen zu GitHub
Was ist GitHub?
GitHub ist eine Online-Plattform zum Speichern, Verwalten und gemeinsamen Bearbeiten von Git-Repositories sowie zur Organisation von Softwareprojekten. Dazu kommen unter anderem Issues, Pull Requests, Releases, Actions und Berechtigungen.
Ist GitHub dasselbe wie Git?
Nein. Git ist das verteilte Versionsverwaltungssystem. GitHub hostet Git-Repositories online und ergänzt sie um Funktionen für Zusammenarbeit, Prüfung, Veröffentlichung und Projektorganisation. Git funktioniert auch ohne GitHub.
Was ist ein Repository?
Ein Repository enthält Projektdateien und deren Versionshistorie. Neben Quellcode können darin Dokumentation, Skripte, Konfigurationen, Binärdateien, Tests oder Beispieldateien liegen. Es ist nicht automatisch ein fertiges Programm.
Was ist ein Release?
Ein Release veröffentlicht einen bestimmten, meist per Tag markierten Projektstand mit Versionshinweisen. Projektverantwortliche können fertige Installationsdateien oder Binärpakete anhängen. Die automatisch angebotenen Source-Code-Archive bleiben Quellcode-Schnappschüsse.
Was ist ein Issue?
Ein Issue ist ein Eintrag zur Erfassung und Diskussion von Fehlern, Aufgaben, Ideen oder Funktionswünschen. Ein offenes Issue ist weder automatisch ein bestätigter Fehler noch ein Support- oder Umsetzungsversprechen.
Was ist ein Pull Request?
Ein Pull Request schlägt vor, Änderungen aus einem Branch oder Fork in einen anderen Branch zu übernehmen. Er dient der Diskussion, Prüfung und möglichen Zusammenführung, lädt aber keine Software auf Ihren Rechner.
Kann jeder Code auf GitHub hochladen?
Kontoinhaber können grundsätzlich eigene Repositories erstellen, sofern sie Plattformregeln und mögliche Organisationsrichtlinien einhalten. In ein fremdes Repository dürfen Sie nur mit passenden Schreibrechten direkt übertragen. Ohne diese Rechte erfolgt ein Beitrag häufig über Fork, Branch und Pull Request.
Ist Software von GitHub sicher?
Nicht automatisch. GitHub stellt die Plattform bereit, prüft aber nicht jedes öffentliche Projekt auf Schadfunktionen, Qualität oder Eignung. Kontrollieren Sie Eigentümer, Dokumentation, Aktivität, Issues, Lizenz, Releases, Abhängigkeiten und vorhandene Integritätsnachweise, bevor Sie Software ausführen.
Der Merksatz: Git verwaltet Versionen, GitHub hostet und organisiert Git-Projekte, und ein Repository sollte vor Download, Ausführung oder Mitarbeit anhand von Zweck, Veröffentlichungsform, Dokumentation, Lizenz und Vertrauenssignalen geprüft werden.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten