Git (Versionsverwaltung)

Er muss als offengelegt gelten und ersetzt werden – ihn im nächsten Commit zu löschen, entfernt ihn nicht. Git fügt im Regelfall nur Daten hinzu; der ältere Commit trägt den Schlüssel weiter. Auch nach umgeschriebener Historie bleibt das Objekt eine Zeit lang erreichbar: Die Git-Dokumentation zu git gc nennt als Standardfristen 90 Tage für Verweise auf frühere Stände und zwei Wochen, bis unerreichbare Objekte aufgeräumt werden. Die GitHub-Dokumentation setzt deshalb das Widerrufen an den Anfang, nicht das Löschen.

Namen, E-Mail-Adressen und Arbeitszeiten aller Beteiligten sowie jede Datei, die je im Projekt lag – auch die gelöschten. Jeder Commit speichert Autor, Adresse und Zeitstempel als Teil seiner Prüfsumme; diese 40 Zeichen lange Kennung ändert sich, sobald eine dieser Angaben nachträglich berichtigt wird. Die Git-Dokumentation warnt, dass eine so umgeschriebene Historie nicht mehr zur ursprünglichen passt und sich nicht einfach verteilen lässt. Deshalb gehört die Durchsicht vor die Veröffentlichung, nicht danach.

Alles, was nicht in der Historie steht, sondern beim Plattformanbieter liegt: Aufgaben und Fehlermeldungen, die Anmerkungen aus den Prüfanfragen, die Konfiguration der Auslieferung und die dort hinterlegten Zugangsdaten. Ein Klon enthält die vollständige Historie, eine ZIP-Datei oder eine FTP-Kopie des laufenden Servers dagegen nicht – ohne das Unterverzeichnis .git ist es ein Stand ohne Vergangenheit. Zu übergeben sind daher Verzeichnis, Plattformkonto und Zugangsdaten, nicht nur die Dateien.

GitHub warnt ab 50 MiB je Datei und lehnt Dateien über 100 MiB ab; über den Browser sind höchstens 25 MiB möglich. Für das ganze Verzeichnis empfiehlt der Anbieter unter 1 GB und dringend unter 5 GB. Git selbst kennt keine solche Schranke, speichert aber jede Fassung einer Datei vollständig, und die Historie wird nicht wieder kleiner. Videos, Rohbilder und Entwurfsdateien gehören deshalb in Git LFS oder eine Ablage daneben.