Nooster schrieb:
Die Daten müssen nicht unbedingt versioniert sein, höchstens falls die Datenbank mal kaputt geht zum wiederherstellen. Eigentlich brauchen wir eher ein Backup als eine Version.
Dann macht doch einfach Backups. 😉
Git kann zwar mit Binärdateien umgehen und manchmal kommt man da auch nicht drum herum. Bilder, Icons, aber auch - generierter Code. zB. TypeScript zu JavaScript oder einfach minifiziertes JavaScript. Oder Markdown/RestructuredText zu HTML.
Das sind dann zwar Textdateien im Ergebnis, aber die sehen ja jedes Mal anders aus (zufällige Variablennamen, andere Strukturierung, etc.) und das in einem Diff zu haben ist dann einfach nicht sinnvoll. Besser man teilt Git mit, dieses Zeug so zu behandeln wie Binärdateien eben (über .gitattributes). (Oder man läßt es ganz weg und wer es haben will muss es eben bei Bedarf neu erzeugen.)
Und für kleine Dateien ist das dann auch okay, aber eine ganze Datenbank? Da platzt dir doch das .git bald aus allen Nähten und jeder Clone überträgt dann ja nicht nur die letzte, sondern alle Versionen davon.
Wenn die Datenbank jetzt keine .sqlite Datei wäre sondern ein Dump (also wieder im Textformat), dann wäre das evtl. was anderes, vorausgesetzt: der Dump ist irgendwie so erzeugt, daß ein Diff Sinn macht also wirklich nur Änderungen zeigt und der Rest bleibt gleich. Bei den meisten Dumps (mehrere Inserts pro Zeile, zufällige Sortierung) kann man das aber auch vergessen.
Die Idee vom gitlfs ist dann, gerade besonders große Binärdateien auszulagern. Wie du das auslagerst ist dann wieder ein anderes Problem, aber im Git selber hast du dann nur Dateiname/Timestamp/Prüfsumme oder sowas. Und wenn du dir das Repository klonst, musst du dir nur die letzte Version von der aktuellen Binärdatei ziehen und nicht die ganze History dazu. Die History kann auf irgendeinem Server oder NAS oder ... vor sich hin versauern.