GIT Migration

Bei einer Migration stellt sich immer die Frage:

Was nehme ich mit? Was lasse ich zurück?

Die GIT History ist so ein Thema, denn die will man meistens behalten, um Entwicklungsschritte nachvollziehen zu können. Aber andere Dinge möchte man gerne vergessen lassen.

Mit meiner geplanten Migration von Bitbucket zu Codeberg kam ich zu dem Schluss, dass ich die History nicht übernehme … oder anders gesagt, ich kopiere einfach die aktuellen Sourcen in ein neues GIT Repository.

Die primäre Grund dafür:

Ich Idiot hatte fette Binärdateien ins alte Repo aufgenommen.

Unter den “externen Bibliotheken” war bekanntlich auch GTK, welches ich eigens für Windows kompiliert hatte. Diese Bibliotheken umfassten viele Megabytes an Binärdateien, die das Repo extrem aufgebläht hatten.

Deshalb erfolgte zuerst die Abspaltung des extlibs Repositories für Fremdbibliotheken und diese durften nur in reiner Source-Form commited werden.
Und dann wurde das gate Projekt nur mit dessen Sourcen separat angelegt.

Anders sieht es beim opengate Repository aus, in dem die Quellen der Webseiten von opengate.at liegen.
Hier klonte ich zuerst das neue leere Repo, fügte dann den Pfad zum alten Repo hinzu, holte die alten Inhalte auf die lokale Maschine und führt dann einen Merge durch, der die alten Inhalte in den Branch des neuen Repos integrierte.

Das sieht dann etwa so aus:

git clone https://new-server.tld/path_to/my_new_project.git
cd my_new_project

git remote add old_stuff https://old-server.tld/path_to/my_old_project.git
git fetch old_stuff
git merge old_stuff/master

git push

Nun kann ich jede Änderung bis zur Erstellung des ersten Blog-Eintrages in GIT zurückverfolgen.

Im Fall vom gate Projekt wäre das vielleicht auch nicht schlecht gewesen, doch hier war mein Ziel mit einem schlanken Repo zu beginnen.

Außerdem bin ich inzwischen ein Fan von squash Mergerequests geworden, bei denen mehrere Commits zu einem zusammengefasst werden.
Mein künftiger main Branch soll nicht jede kleine Änderung erhalten, sondern nur noch gesammelte fertige Features (oder fertige Blogposts).
Schließlich bringt es nichts, 1000 einzelne Commits zu speichern, bei denen immer nur ein Zeilchen angepasste wurde.

Fazit

Die GIT Migration zu Codeberg geht gut voran, obwohl ich jetzt auch noch viele weitere Kleinigkeiten fixen muss, damit das Gesamtsystem wieder so bauen kann wie vorher … und das auf allen gewünschten Plattformen.

Migrationen sind mühsam, aber bieten immer auch eine gute Gelegenheit um aufzuräumen, denn:

Nur saubere GIT Repos sind gute GIT Repos.