(Не) храните большие бинарные файлы в git
Есть такое общеизвестное правило - никогда не храните большие бинарные файлы в git. Почему?
Причин несколько:
1) большие файлы как правило бинарные, а при работе с бинарными файлами мы теряем значительную часто возможностей git - просмотр diff-ов, да процесс code review в целом
2) git начинает тормозить при разрастании репозитория, а учитывая, что хранится вся история изменений - с большими файлами выйти на этот предел (десятки и сотни Gb, вот тут есть пример от Microsoft https://t.me/javaKotlinDevOps/272) уже значительно проще.
И если с первой причиной что-то сделать сложно, то для второй решение есть. И называется оно Git LFS https://git-lfs.com/
Для начала небольшая справка. При git clone скачивается следующая информация:
1) метаданные
а) настройки git
б) список существующих веток и тэгов
2) история коммитов по всем веткам (.git)
3) актуальные версии файлов в текущей ветке
Суть решения:
1) большие файлы хранятся отдельно от текстовых, с текстовыми файлами хранятся только ссылки на них. Переиспользуем возможности файловой системы Linux
2) при клонировании репозитория большие файлы копируются только для текущей ветки, что ускоряет загрузку
Главный вопрос - когда это все может понадобится? Видится такой вариант - хранить контент вместе с исходниками. Вообще контент лучше хранить в CMS, но, например, если есть тесная связь контента с релизом, то может иметь смысл хранить их рядом. Что точно не стоит хранить в git - так это jar-ники.
Еще важный момент - для того, что Git LFS заработал, нужно:
1) проинсталлировать его на сервере
2) включить на репозитории
3) добавить в репозиторий по маске список файлов, которые надо считать большими.
4) существующие файлы в LFS не попадают, их нужно добавить заново или мигрировать
В целом LFS работает прозрачно, но команды git lfs clone и git lfs pull оптимизированы для работы с LFS и загружают данные быстрее.
Проект open source и поддерживаемый, был создан усилиями заинтересованных лиц - GitHub, Bitbucket.
#git
Есть такое общеизвестное правило - никогда не храните большие бинарные файлы в git. Почему?
Причин несколько:
1) большие файлы как правило бинарные, а при работе с бинарными файлами мы теряем значительную часто возможностей git - просмотр diff-ов, да процесс code review в целом
2) git начинает тормозить при разрастании репозитория, а учитывая, что хранится вся история изменений - с большими файлами выйти на этот предел (десятки и сотни Gb, вот тут есть пример от Microsoft https://t.me/javaKotlinDevOps/272) уже значительно проще.
И если с первой причиной что-то сделать сложно, то для второй решение есть. И называется оно Git LFS https://git-lfs.com/
Для начала небольшая справка. При git clone скачивается следующая информация:
1) метаданные
а) настройки git
б) список существующих веток и тэгов
2) история коммитов по всем веткам (.git)
3) актуальные версии файлов в текущей ветке
Суть решения:
1) большие файлы хранятся отдельно от текстовых, с текстовыми файлами хранятся только ссылки на них. Переиспользуем возможности файловой системы Linux
2) при клонировании репозитория большие файлы копируются только для текущей ветки, что ускоряет загрузку
Главный вопрос - когда это все может понадобится? Видится такой вариант - хранить контент вместе с исходниками. Вообще контент лучше хранить в CMS, но, например, если есть тесная связь контента с релизом, то может иметь смысл хранить их рядом. Что точно не стоит хранить в git - так это jar-ники.
Еще важный момент - для того, что Git LFS заработал, нужно:
1) проинсталлировать его на сервере
2) включить на репозитории
3) добавить в репозиторий по маске список файлов, которые надо считать большими.
4) существующие файлы в LFS не попадают, их нужно добавить заново или мигрировать
В целом LFS работает прозрачно, но команды git lfs clone и git lfs pull оптимизированы для работы с LFS и загружают данные быстрее.
Проект open source и поддерживаемый, был создан усилиями заинтересованных лиц - GitHub, Bitbucket.
#git
Telegram
(java || kotlin) && devOps
Всем привет!
Минутка истории. И разных подходов к работе с opensource.
1-я история. Жила была компания Microsoft, и в какой-то момент она "запустила" свою инфраструктуру разработки. Были выделены ресурсы для исправление этой ситуации. Один из примеров такой…
Минутка истории. И разных подходов к работе с opensource.
1-я история. Жила была компания Microsoft, и в какой-то момент она "запустила" свою инфраструктуру разработки. Были выделены ресурсы для исправление этой ситуации. Один из примеров такой…
AI и leetcode
Есть ряд известных компаний, предлагающих решение алгоритмических задачек на собесах. Почему они так делают в целом понятно - проверка алгоритмического мышления кандидата и навыков \ скорости написания кода.
Что меняется с появлением AI?
1) видится, что пользоваться AI на таких собесах не разрешат, т.к. современные агенты не просто могут решить задачку, но и даже написать тесты, проверяющие ее решение. Т.е. с AI никакой проверки на собесе не будет
2) в целом ничего не меняется - такие задачки как проверяли способности к мышлению, проектированию и кодированию, так и проверяют. Я думаю, что они останутся
3) но возникает интересный момент. Вот решил кандидат за 1.5 часа 3 задачки. Даже 10 минут в резерве осталось. Появляется чувство: "А я хорош!)". Возникает мысль - интересно, а AI агент эти задачки решит. И агент решает их за 10 минут... И какие-то самые некрасивые мысли лезут ко мне в голову...
#ai #interview #algorithms
Есть ряд известных компаний, предлагающих решение алгоритмических задачек на собесах. Почему они так делают в целом понятно - проверка алгоритмического мышления кандидата и навыков \ скорости написания кода.
Что меняется с появлением AI?
1) видится, что пользоваться AI на таких собесах не разрешат, т.к. современные агенты не просто могут решить задачку, но и даже написать тесты, проверяющие ее решение. Т.е. с AI никакой проверки на собесе не будет
2) в целом ничего не меняется - такие задачки как проверяли способности к мышлению, проектированию и кодированию, так и проверяют. Я думаю, что они останутся
3) но возникает интересный момент. Вот решил кандидат за 1.5 часа 3 задачки. Даже 10 минут в резерве осталось. Появляется чувство: "А я хорош!)". Возникает мысль - интересно, а AI агент эти задачки решит. И агент решает их за 10 минут... И какие-то самые некрасивые мысли лезут ко мне в голову...
#ai #interview #algorithms