Git-репозиторий задыхается от тысяч тегов: одно решение от бывшего инженера ZipRecruiter
Maybe a better way to track the release history of a Git repo
В монорепозитории ZipRecruiter развертывания создавали тысячи тегов вида refs/release/stg.www.our-app-...-treesha-..., что замедляло Git и засоряло вывод команд. Автор предлагает хранить историю релизов в виде цепочки метаинформационных коммитов с двумя родителями: один — коммит релиза, другой — предыдущий метаинфо-коммит. Один ref на пару (tier, app) вместо тысяч. Решение использует штатные механизмы Git и не требует сортировки тегов для поиска последнего развертывания.
Git хорошо спроектирован для обработки тысяч коммитов, но не для обработки тысяч ref-ов.
- 1718627440
Можно прийти к тому же решению, особо не задумываясь обо всём этом, просто вливая изменения в релизную ветку при выпуске релиза.
- lijok
Или закоммитить в main файл, который представляет релиз, и строить свои автоматизации на его основе.
- unsloppable
Круто и умно.
Один вопрос: для чего вы используете свои старые ссылки?
Мы просто удаляем их, когда их становится слишком много.