Git-Repo mit Tausenden von Refs? Ein Commit pro Release löst das Problem
Maybe a better way to track the release history of a Git repo
Ein Git-Monorepo sammelte Tausende von Tag-Refs für Deployments an – jede Operation wurde langsamer. Der Autor schlägt vor, die Release-Historie stattdessen als verkettete Metainfo-Commits zu speichern: Jedes Release erzeugt einen Commit mit zwei Parents (vorheriger Release-Commit und vorheriger Metainfo-Commit), sodass pro (Tier, App)-Paar nur ein einziger Ref nötig ist. So lassen sich Releases mit Standard-Git-Befehlen wie git log durchsuchen und zurückrollen.
Ich schlug diese Alternative 2019 vor. Sie speichert die Deployment-Historie jeder App als eine Reihe unbenannter, aber verwandter Git-Objekte unter Verwendung von Gits eigenem History-Mechanismus, sodass sie einfach, effizient und gut mit Gits Befehlen harmoniert.