Un solo ref para gobernar el historial de releases de Git
Maybe a better way to track the release history of a Git repo
En ZipRecruiter, el monorepo acumulaba miles de tags de deployment, ralentizando Git y dificultando consultas como cuándo se desplegó una app por última vez. El autor propone reemplazarlos por una cadena de commits de metainformación, cada uno con dos padres: el commit de release y el commit de metainformación anterior. Así, un único ref por par (tier, app) permite usar git log y otras herramientas nativas para consultar, filtrar y revertir releases de forma eficiente.
Git está bien diseñado para manejar miles de commits, pero no para manejar miles de refs.
- 1718627440
Más o menos puedes llegar a la misma solución, sin pensar realmente en todo esto, simplemente haciendo merge a una rama de release cuando haces un release.
- lijok
O haz commit de un archivo a main que represente un release y construye tus automatizaciones a partir de eso
- unsloppable
Genial e ingenioso.
Una pregunta: ¿para qué usas tus refs antiguos?
Nosotros simplemente los borramos cuando tenemos demasiados.