Комментарии 11
А зачем вы до lfs(тут боюсь тролить потому что не работал с lfs) делали бэкапы гита?
Вроде бэкап гита у каждого разработчика, по крайней мере так было днем когда я делал коммит.
Бэкап есть у меня и ещё у нескольких тысяч моих коллег
Ну, для начала, бекап не гита, а гитлаба.
Гитлаб - это же не только кодики, которые под vcs, это и юзеры-логины-пароли-ключи, это переменные для CI, раннеры и дофига чего еще.
Далее, было бы ошибкой предполагать, что при падении gitlab как некоего общего source of truth вы запросто сможете восстановиться без потерь. Напомню, что у Вас и тысяч Ваших коллег есть данные (кстати, потенциально неактуальные) только по тем репам, которые вы пуллили давеча. По остальным репам информации у вас нет.
При этом кто-то из нескольких тысяч Ваших коллег мог запросто запушить последние изменения и грохнуть локальную репку, а еще некоторые могли внести изменения прямо через webide гитлаба.
И даже если (теоретически) можно в итоге поскрести по сусекам и собрать хоть какое-то общее хранилище кода - времени это займет столько, что Вы триста тысяч раз пожалеете, что не бекапили гитлаб.
Децентрализация гита - она только в головах. На практике дело обстоит намного хуже.
Я в курсе что такое гитлаб и что это не только кодики, в сбере поднимал ажур на команду из 50 человек и успешно мигрировал через 4 версии, включая переход с tsvc на гит, и такого говна не встречал. Повторюсь как в коменте ниже, все должно делатся гораздо проще и навкрняка делается в гитлаб просто вы не стали копать, а решили поупражняться в написании велосипедов.
Отдельное спасибо за минусы
Да, смысл именно в бэкапе гитлаба, а не гита. Полностью согласен с комментом metamorph
Если я правильно понимаю механизм LFS, то в гите хранятся только хеши файлов, сами файлы хранятся на сервере, у разработчиков на компе есть файлы только от текущего комита, всех остальных нету, по типу как в SVN, где твой локальный репозиторий отражает только выбранную ревизию, а не весь репозиторий целиком.
Статья, конечно, забавная, прям начиная с фразы "по историческим причинам".
Ох, сколько ада в этом мире оправдано этими словами. Приходишь в новую компанию, видишь полную хрень, спрашиваешь: почему так? По историческим причинам!
Потом растешь до большого начальника, творишь полную хрень в интересах бизнеса (сейчас быстренько накостыляем, а потом сделаем норм). Выводишь на работу новых сотрудников, а они спрашивают, почему так. По историческим причинам, вот почему! ))
---
Детально не читал, но версия гитлаба из статьи и скрипт ротации бекапов явно устарели. Не совсем уверен, зачем он такой, но современные гитлабы как бы самостоятельно умеют ротировать свои бекапы, и даже самостоятельно заливают их на любое внешнее хранилище (например, s3)
Короче, как руководство к действию я бы не стал принимать. Есть способы намного проще.
уж незнаю за что минусуют, я бы плюсанул, но увы кармы нет
Вот да, работал с Azure Devops, там бэкап базы данных делается из графического интерфейса(репозитории тоже хранятся в бд, даже гитовые) и потом также накатывается. Уверен гитлаб тоже все это умеет из коробки. А не вот это вот все, что нам автор тут показал, если только он не с говном мамонта работает
Из-за огромного количества багов с LFS и прочими причудами вылезающими с новыми версиями(добило gitlab.com/gitlab-org/gitlab/-/issues/271576) — избавились от LFS вообще.
По опыту: гитлаб пытается в энтерпрайз, но сам — коленная поделка, собранная из говна и палок.
Вот из-за этого https://gitlab.com/gitlab-org/gitlab/-/issues/23625 мы перенесли все, что работает с LFS, на GitHub
Как мы переезжали на новую версию GitLab и внедряли LFS. А потом чинили бэкапы