Git-Refs statt Tausender Tags: Ein neuer Weg zur Release-Historie
Maybe a better way to track the release history of a Git repo
In einem großen Git-Monorepo bei ZipRecruiter wuchs die Zahl der Refs durch Deployment-Tags auf Tausende an, was Git spürbar verlangsamte. Der Autor schlägt vor, die Release-Historie stattdessen als verkettete Metainfo-Commits zu speichern: Pro (Tier, App)-Paar gibt es nur noch einen einzigen Ref, der auf den Kopf einer Liste zeigt. Ältere Releases lassen sich per git log zurückverfolgen. Das nutzt Git-Mechanismen und vermeidet Ref-Wildwuchs.
Ich habe diesen Alternativvorschlag 2019 gemacht. Er speichert die Deployment-Historie jeder App als eine Reihe unbenannter, aber verwandter Git-Objekte unter Verwendung von Gits eigenem History-Mechanismus, sodass er einfach, effizient ist und gut mit Gits Befehlen harmoniert.
- 1718627440
Man kann irgendwie zur selben Lösung gelangen, ohne tatsächlich über all das nachzudenken, indem man einfach in einen Release-Branch merged, wenn man ein Release macht.
- lijok
Oder committe eine Datei in main, die ein Release repräsentiert, und baue deine Automatisierungen darauf auf
- unsloppable
Cool und clever.
Eine Frage: Wofür verwendest du deine alten Refs?
Wir löschen sie einfach, wenn wir zu viele haben.