Zuerst das wissenschaftliche Zitierobjekt bestimmen
Ein GitHub-Repositorium kann Quellcode, Daten, Dokumentation, Issues und fortlaufende Entwicklung enthalten. Der Link auf die Projektwurzel benennt deshalb noch nicht, welche Fassung ein Ergebnis erzeugt hat. Lege fest, ob du eine bestimmte Softwareversion, einen einzelnen Codezustand, ein Datenrelease oder nur die Projektbeschreibung belegen willst. Im Methodenteil wird zusätzlich erklärt, wie der Code verwendet wurde.
Prüfe, ob das Projekt eine Datei CITATION.cff, eine Zitierfunktion, eine DOI oder eine bevorzugte Zitationsangabe in README beziehungsweise Dokumentation anbietet. Übernimm diese Angaben nicht blind: Vergleiche Titel, Personen, Version und Datum mit dem verwendeten Stand. Die Softwareautorinnen können andere sein als die Eigentümer des Plattformkontos.
Ein Release ist die verständlichste technische Fassung
Ein Release bündelt einen markierten Stand und trägt häufig eine Versionsnummer wie 2.1.0. Er ist für Menschen leichter zu benennen als ein langer Hash und kann Quellarchive sowie Hinweise zu Änderungen enthalten. Verwende genau den Release, mit dem deine Analyse lief. Ein späterer Release darf nicht rückwirkend an seine Stelle treten, auch wenn er Fehler behebt.
Notiere die auf der Release-Seite ausgewiesene Version und das Veröffentlichungsdatum. Prüfe, ob der Tag tatsächlich auf den erwarteten Commit zeigt. Bei eigener Software erstellst du den Release erst nach einem sauberen Test und dokumentierst Abhängigkeiten. Ein Tag auf GitHub verbessert Versionierung, garantiert aber allein keine dauerhafte externe Archivierung.
Commit zitieren, wenn kein Release passt
Bei laufender Entwicklung oder einer unveröffentlichten Korrektur kann der vollständige Commit-Hash die präziseste Referenz sein. Kurze Hashes sind bequem, aber der vollständige Wert ist eindeutiger. Nenne zusätzlich Repositorium, Autorenschaft, Titel, Datum oder Jahr und URL. Halte das Abrufdatum fest, weil Plattform und Zugänglichkeit sich verändern können.
Ein Commit verweist auf einen Codezustand, aber nicht automatisch auf externe Abhängigkeiten, Daten oder Laufzeitparameter. Verbinde ihn mit dem Environment-Protokoll, der Datenversion und dem verwendeten Startbefehl. Bei privaten Repositorien kann der Verweis für Prüfende unzugänglich sein; vereinbare dann einen institutionell kontrollierten Abgabeweg.
Ein Archiv ergänzt die Entwicklungsplattform
Forschungsarchive wie Zenodo können einen GitHub-Release übernehmen, Metadaten speichern und einen DOI vergeben. Der DOI verweist auf eine archivierte Version; eine übergeordnete DOI kann eine Sammlung von Versionen beschreiben. Für die Reproduktion sollte die konkrete Version zitiert werden. Prüfe auf der Archivseite, welche Releasekennung der Datensatz tatsächlich enthält.
Archivierung erfordert aufgeräumte Metadaten, Rechte und Lizenz. Entferne Zugangsdaten, personenbezogene Informationen und nicht weitergebbare Bibliotheken bereits aus der Versionsgeschichte. Ein öffentliches Archiv lässt sich nicht wie ein privater Arbeitsordner behandeln. Wenn Offenlegung nicht möglich ist, können öffentliche Metadaten plus kontrollierter Zugang die ehrlichere Lösung sein.
Aus Metadaten einen vollständigen Beleg bauen
Ein belastbarer Datensatz enthält Urheberinnen oder Projekt, Softwaretitel, Versionskennung, Jahr, Bezeichnung als Software, Archiv oder Plattform und DOI oder stabile URL. Ergänze das Abrufdatum, wenn dein Stil oder ein veränderliches Ziel dies verlangt. Für ein konkretes Codefragment kann der Text zusätzlich Datei, Funktion und Zeilenbereich nennen; Zeilennummern allein sind jedoch ohne feste Version instabil.
Beispielschema: „Nachname, Vorname; Projektteam (Jahr): Titel der Software, Version X.Y, Software. Archiv. DOI.“ Für einen Commit: „Projektteam (Jahr): Repositoriumstitel, Commit [vollständiger Hash], GitHub, URL, abgerufen am …“. Passe Zeichensetzung und Namensreihenfolge an den Zitierstil deiner Hochschule an.
Codezitat, Methodenbeschreibung und Lizenz trennen
Die Quellenangabe würdigt Herkunft und macht die Version auffindbar. Der Methodentext erklärt Installation, Eingaben, Parameter und Änderungen. Die Lizenz regelt, welche Nutzung und Weitergabe erlaubt ist. Keine dieser Ebenen ersetzt die anderen. Wenn du fremden Code verändert hast, verweise auf das Original, dokumentiere deinen Fork oder Patch und beachte Lizenzhinweise.
Prüfe vor Abgabe jeden Beleg aus einer nicht angemeldeten Sitzung. Öffnet der DOI die richtige Version? Stimmen Release, Tag und Commit? Ist der zitierte Stand im Literatur- oder Softwareverzeichnis und an der relevanten Methodestelle genannt? Sichere die Zitationsmetadaten zusammen mit dem Reproduktionspaket.
Zitationsangaben im Team verbindlich festlegen
Bei gemeinsam entwickelter Software klärt das Team vor dem Release, welche Personen oder Organisationen als Urheber genannt werden, wie Beiträge anerkannt und welche Reihenfolge verwendet wird. Die Datei CITATION.cff sollte mit Archivmetadaten, Lizenz und README übereinstimmen. Ändert sich Autorenschaft zwischen Versionen, wird der konkrete Release zitiert und nicht eine spätere Namensliste rückübertragen. Prüfe auch Sonderzeichen und eindeutige Personenkennungen. Für mehrere Softwarekomponenten führst du getrennte Belege statt eines Sammellinks. So bleibt erkennbar, welche externe Bibliothek, welche eigene Erweiterung und welche ausführbare Gesamtfassung jeweils zur Analyse beigetragen haben.