после ребейза главных веток обычно следует рассылка с текстом "посоны и дамы, переклонируйте репозиторий и, пожалуйста, не бейте меня ногами по голове"

но иногда это необходимость. вычистка репы от лишних тяжелых файлов и/или перевод на LFS - как раз один из сценариев, когда можно сохранить черепушку целой

так lfs только локальные репы уменьшает. он же на структуру и объем собственно репозитория не влияет

смотря где хранятся lfs-файлы :)

понятно. но общий же объем не меняется :)

Но скорость работы с репой увеличится

но lfs полезен не только локальному разрабу. на CI в реалиях 1сных конфигураций получается дикий буст времени подготовки репозитория к тестированию. там где раньше реп клонировался минуту, после перехода на лфс становится 15 секунд. в мульти-стэйдж билдах это очень быстро выливается в сэкономленные машиночасы

с этим не могу поспорить :) хочу лишь добавить что когда отказались на паре сборок от конфигураций поставщика в cf, то тоже скорость увеличилась, а размер уменьшился :)

Так там cf ник

Конечно, станет всё легче и быстрее

картинки/макеты/архивы тоже порядком занимают. при частых апдейтах конфигурации поставщика, на них много набегает

А вот такой вопрос:
Есть репо с внешними обработками. Исторически так сложилось, что помимо исходников в этом репо лежат и скомпилированные epf-ки.
Хочется почистить проект от epf-ок, но есть нюанс:
Некоторые файлы, которые нужны для сборки итоговой обработки, не отслеживались (например, бинарники макетов).
Получается, что если удалить все epf-ки, то собрать обратно произвольную версию не получится. Как это можно обойти? Я подумываю в сторону релизов  (просто на значимые версии создать релизы в GitLab). Это ОК или не очень?

а получается что практики именно обрезки репозитория по датам нет? в случае необходимости он просто очищается и пересоздается что ли?

по датам - не встречал. вся польза гита наоборот от длинной истории :)
а вот вырезание тяжелых/случайных бинарей - частая задача

ну а какой прок от истории двухлетней давности например? уже и типовой код сто раз поменялся и люди уволились :)

либо релизы либо внешний artifactory. хранить собранные релизы - задача понятная и логичная.
стоит сохранить epf заранее, а после чистки репы развесить их по тегам, т.к. теги после ребэйза тоже поплывут.
ну и после такой чистки имеет смысл класть в гит полноценные исходники, достаточные для сборки. после этого можно настроить автодеплой собранных обработок в тег, например. счастье, космос и вот это все.

пару дней назад залезал в историю четырехлетней давности в попытках понять, почему код был написан именно так, по каким задачам и в каком контексте :)

ну и хранилище регулярно умирает, а гит вечен! :D

у нас обратный случай был :)