Den vorhandenen Repository-Zustand zuerst erhalten
Starte nicht mit interaktivem Rebase, Squash oder neuen „Erklär-Commits“. Solche Änderungen können die ursprüngliche Abfolge überschreiben. Sichere den aktuellen Arbeitsbaum, alle relevanten Branches, Tags, Commit-IDs und die konfigurierten Remotes. Notiere den Zeitpunkt der Sicherung und ob uncommittete Dateien vorhanden waren. Eine Kopie oder ein Bundle bleibt getrennt von der Arbeitsversion.
Erfasse außerdem, ob das Projekt lokal, auf einer Hostingplattform oder in mehreren Repositories geführt wurde. Ein öffentliches Remote kann zusätzliche Zeitangaben, Pull Requests und Reviews enthalten; ein lokaler Commit kann nie gepusht worden sein. Beschreibe diese Unterschiede, statt eine Quelle als automatisch vollständig zu behandeln. Verwende keine fremden Zugangsdaten und veröffentliche kein privates Repository zur Beweisführung.
Commits inhaltlich statt nur chronologisch lesen
Eine lange Historie ist nicht automatisch aussagekräftig. Wähle Meilensteine: erste Struktur, Import einer Datenquelle, Implementierung einer Methode, Korrektur nach Feedback, neue Tests und Abgabezustand. Erkläre anhand des Diffs, welche Entscheidung sichtbar wird. Ein Commit mit tausenden generierten Dateien kann weniger über Eigenleistung aussagen als eine kleine, begründete Änderung samt Test.
Prüfe Elternbeziehungen und Branches. Ein Merge bündelt fremde und eigene Commits; ein Cherry-pick kann eine Änderung mit neuer Kennung wiederholen. Submodule verweisen auf ein anderes Repository. Große Binärdateien zeigen im Diff häufig nur, dass Bytes gewechselt haben. Behaupte dort keine inhaltliche Entwicklung, wenn sie nicht durch eine lesbare Quelldatei oder Begleitnotiz gestützt wird.
Commit-Nachrichten können den damaligen Zweck erläutern, sind aber selbst verfasste Metadaten. Verbinde sie mit Code, Tests, Issues oder Reviewkommentaren. Bei Textprojekten zeigen Diffs Einfügungen und Löschungen; sie erklären nicht automatisch, woher eine eingefügte Passage stammt. Quellenaufzeichnungen, Notizen und frühere Entwürfe schließen diese Lücke.
Autorfeld, Zeitstempel und Signatur richtig einordnen
Name und E-Mail im Commit werden lokal konfiguriert. Sie ordnen das Objekt einer angegebenen Identität zu, bestätigen aber nicht die Person am Gerät. Author date und committer date können voneinander abweichen und ebenfalls gesetzt werden. Hosting-Zeitpunkte oder externe Reviews können zusätzliche Anhaltspunkte liefern, ersetzen aber keine inhaltliche Prüfung.
Eine kryptografisch signierte Änderung bestätigt unter geeigneter Schlüsselverwaltung, dass der Commit mit einem bestimmten Schlüssel signiert wurde. Sie beweist nicht, wer den Schlüssel im Moment benutzt hat oder ob der Inhalt eigenständig entstand. Formuliere daher exakt: „Die Plattform zeigt den Commit als mit Schlüssel X verifiziert“ statt „Der Commit beweist meine Urheberschaft“.
Git erfasst außerdem nur gespeicherte Commits. Recherche, Skizzen, Gespräche, lokale Experimente und verworfene Dateien können fehlen. Ein nachträglich importierter Verlauf bleibt eine Rekonstruktion. Die allgemeine Seite Versionen als Eigenleistungsnachweis hilft, Git mit anderen Versionsarten zu verbinden.
Ein prüfbares Git-Nachweispaket zusammenstellen
Beginne mit Repository-Kennung, Sicherungsdatum, relevantem Branch und Abgabestand. Danach folgen die Timeline, wenige kommentierte Diffs und ein Anlagenindex. Gib Befehle oder Plattformansichten so an, dass eine fachkundige Person die Auswahl reproduzieren kann. Enthält das Projekt Geheimnisse, personenbezogene Daten oder fremden Code, kläre einen geschützten Prüfweg und lege nicht pauschal alles offen.
- Originalzustand und uncommittete Änderungen getrennt sichern.
- Commit-IDs vollständig im Anhang erhalten.
- Zeitzonen und Author-/Committer-Daten benennen.
- Jeden Meilenstein mit einer fachlichen Entscheidung verbinden.
- Tests und externe Begleitspuren nur nennen, wenn sie vorliegen.
- Merge-, Import- und Generierungsanteile kennzeichnen.
- Grenzen für Identität, Vollständigkeit und Zeit offenlegen.
Der Hub Prüfungsverfahren ordnet das Paket ein. Für nichttechnische Prozessspuren ist Betreuungsfeedback als Kontext relevant. Genau eine Grundlagenseite ist verlinkt: Wissenschaftlich arbeiten.
Beispiel für eine begrenzte Commit-Aussage
Eine belastbare Formulierung könnte lauten: „Commit C-07 ergänzt die Validierung leerer Eingaben und fügt drei zugehörige Tests hinzu. Das Issue I-03 dokumentiert die zuvor beobachtete Fehlermeldung; der erhaltene CI-Lauf war für genau diesen Commit erfolgreich. Diese Unterlagen zeigen die gespeicherte Änderung und ihre technische Prüfung. Sie bestätigen nicht, welche nicht gespeicherten Versuche vorausgingen oder wer das Autorenkonto bediente.“
Für ein Textkapitel gilt dieselbe Logik: „Zwischen C-11 und C-12 wurde die Diskussion um zwei Absätze erweitert. Die drei neu zitierten Originalquellen stehen im zeitgleichen Literaturprotokoll. Ein Betreuungsreview kommentiert anschließend genau diese Passage.“ Eine solche Kette bleibt prüfbar, ohne aus dem Commit mehr abzuleiten, als seine Daten tragen.