Контроль версий, геймдев и git lfs

Tulenber 16 December, 2019 ⸱ Beginner ⸱ 6 min ⸱

Эта статья начиналась как заметка про git и Unity… а потом поток мыслей вышел из-под контроля =)

Тут не будет ещё одной статьи “Что такое контроль версий?” или “Зачем вам нужен контроль версий в XXI веке?”. Лучше опишем текущее положение и почему в геймдеве всё несколько иначе, чем в более других областях и что с этим можно сделать.

Ах да, тут будут приведены цены на сервисы сторонних компаний, автор никак не связан с этими компаниями, а так же не несёт никакой ответственности за ваши расходы.

Контроль версий, он ж Version Control System, он же VCS

Для тех кто НЕ знаете что это такое - запомните одну простую мысль: “Всегда используйте VCS!". Так что берите поисковик в руки и ищите “Github for beginners”, делайте, что там сказано, а потом сразу идите и читайте Pro Git.

Для тех кто знает что это, скажу, что я посоветовал git и GitHub, потому что они покроют всё необходимое для начала, а, скорее всего, и для всех рабочих моментов. А также скажу своё мотто: “В начале проекта было 2 слова. И слова эти были git init”, ну вы поняли, просто как напоминание.

Среднестатистическая компания

  • Старые добрые компании и(или) проекты - вы сидите на svn. Навряд ли в ваших силах поменять его на что-то другое раз проект до сих пор на нём, но вы можете попробовать - безумству храбрых поём мы песню. В любом случае ещё одна статья про миграцию не нужна вам. Но всегда можно найти плюс - хуже уже не будет! Крепитесь, морально мы с вами.

  • Немного параноидальные - если вы параноик, то это не значит что за вами никто не следит. Свой сервер в “закрытой” сети. Это 21 век - тут никто не осуждает… ну или вас государство обязало. На примере гита можно предположить разделение по стоимости Gitea < GitLab < GitHub Enterprise. Это что-то из текущего века и то хорошо.

  • Хипстеры - сейчас можно встретить компании, которые используют тот же самый GitHub для хранения своих исходников и у них всё нормально. Надеюсь, у Вас тоже всё хорошо и вы не страдаете.

Геймдев

В геймдеве есть своя специфика в контроле версий и заключается она в наличии большого количества ресурсов в виде картинок, роликов и тому подобного контента, который весит очень много (По-человечески это называется BLOB, Binary Large Object - большой двоичный объект). Один из моих проектов занимал 10Гб из них 7Гб были арты. Git не рассчитан на хранение blob’ов и в результате появляется разделение исходного кода и ресурсов. В любом уважающем себя проекте появится какой-нибудь инструментарий для упрощения жизни и немалую его часть занимает решение этой проблемы. Не стоит переоценивать её величину, живут же как-то люди. Но я попадал в ситуацию, когда правила игры с blob’ами менялись внутри команды, иногда ради процессов, иногда ради стоимости. Так, почему бы не поменять их на что-то модное и хипстерское?

Варианты решения для геймдева

Думаю можно признать, на данный момент стандартом де-факто является git, так что в голову сразу приходят такие решения:

  • Кастомный инструментарий - тоже вариант, работает по принципу маленькие детки - маленький тулинг, большие детки - большой тулинг. Можете поискать статьи про монорепозитории, Facebook и их тулзы. Как уже упоминалось ранее blob’ы хранятся отдельно. Внутри компании на отдельном сервере. Для распределённой работы могут запихнуть всё в dropbox или yandex.drive. В итоге, ветвление следующей версии для стабилизации на прод будет сопровождаться фразой в общем чатике: “Для артов версии 1.6.0 создана папка 1.6.0, все изменения художников должны идти ТУДА!!!”. Ну или ростом тулинга =)

  • Perforce - говорят что он пользуется популярностью в геймдеве и других медийных областях и умеет хранить в себе blob’ы, а ещё там есть гитовая обёртка. Их подход звучит: "Start Free and Pay as You Grow", как и у всех современных сервисов, так что если у вас есть возможность, то почему бы и нет (для больших команд всего лишь в 2 раза дороже чел/мес чем GitHub, декабрь 2019).

  • Git - как разработчика гит меня вполне устраивает, а для решения всех проблем с blob’ами, собрались несколько крупных игроков на рынке и написали для него плагин: git lfs. По сути, это тот же самый дополнительный инструментарий, но встроенный в ваш git клиент. Никакой особой магии тут нет: в локальном репозитории файлы хранятся как есть, а в удалённом хранится ссылка на версию файла в каком-то файловом хранилище. Ничего сложного, для полного описания можно сходить на сайт проекта там есть вся необходимая вводная информация.

Git lfs

Когда слышишь фразу: “в каком-то файловом хранилище” - сразу чувствуешь где-то тут подвох. Что за сервер, где его взять, сколько стоит и т.п. На самом деле, это даже удивительно, сколько проблем вызывает консолидация информации по этой фиче, учитывая, что её пилили все гранды и за её использование они берут приличные деньги, а вот про маркетинг забыли. Есть несколько имплементаций серверов, не считая сервисы, это опенсурсные поделия, есть даже под AWS Lambda, но, может быть, это не так плохо? Мне хотелось разобраться с git lfs и вот что я накопал (декабрь 2019):

  1. Базовый вариант - облако, не нужно ничего делать, оно всё работает само:

    • GitHub - 1Гб места под файлы и 1Гб трафика в месяц под все проекты. Дополнительные пакеты по 5$ за 50Гб места и 50Гб трафика (Спрятали прайс внутри настроек аккаунта, кнопка Billing).

    • Bitbucket - 1Гб места под все проекты, про трафик не упоминают. Дополнительное место по 10$ за 100Гб места (прайс). Похоже на самое приемлемое.

    • Azure DevOps Service - 2Гб места и что-то около 1$ за Гб сверху (прайс). Не надо на меня так смотреть, мы на пороге 2020 года, Майкрософтом пользоваться не зазорно.

    • GitLab - как всегда, уже год находится в состоянии “Currently, we have a 10GB/repository limit with no option for users to increase their storage and we will add this feature later.” (ссылка). Можно ли им пользоваться? Больше 10Гб вы не получите, один из первых комментов, что это show stopper for gamedev, но кто может вам запретить?

  2. Гибридный вариант - вам уже придётся настраивать что-то руками, но хранить по-прежнему будем в облаке:

    • AWS S3 - например, git-lfs-s3, около 0.02$ за Гб и ещё по 0.1$ за Гб трафика из облака плюс ещё запросы (прайс). На первый взгляд, приемлемо, но с Амазоном нужно быть ОЧЕНЬ осторожным (автор не несёт ответственности за ваши расходы).

  3. Полугибридный вариант - blob’ы храним у себя:

    • Nexus Repository Manager - используют в корпорациях, и я сильно удивился увидев его в геймдеве для всяких репозиториев питона. Ещё оно контейнеры для докера умеет хранить и, вообще, почти всё, что приходит в голову, так почему бы на него ещё и lfs не повесить?

  4. Мидкор - всё у себя в норе:

    • GitHub Enterprise, Bitbucket Server и Microsoft DevOps Server - судя по документации умеют, если у вас есть деньги и такие требования, то почему вы ещё не купили? оО

    • GitLab - в отличие от облачной версии, место ограничивается вашими дисками и добротой человека, настраивающего конфиги.

    • Gitea - тоже имеет встроенный lfs, нужно только включить в настройках, вопрос только насколько оно рабочий вариант для боевого использования.

  5. Хардкор:

    • Вместо инструментов, который у Вас есть для разруливания blob'ов, можно написать свою имплементацию lfs сервера, который точно так же будет класть всё в S3 или куда душе заблагорассудится. Зачем изобретать свой велосипед с 0, если можно взять чертежи и раму со стороны?

В итоге git lfs выглядит вполне живым решением (используется для этого блога), а для маленьких домашних проектов развёртывание дополнительной инфраструктуры того не стоит, так что я остановился на… думаю понятно по картинке в заголовке. Пока! =)



Privacy policyCookie policyTerms of service
Tulenber 2020