Git великолепен. Это также источник боли и украдет вашу душу.

С момента создания Steel Hunters я боролся с тем, как лучше всего управлять контролем версий для проекта. Управлять Unreal Engine достаточно просто, так как Epic структурировала свой репозиторий так, чтобы он был максимально удобен для git.

Собственно игровые проекты, созданные с помощью Unreal Engine: не так уж и много. Особенно, если это достаточно масштабный, качественный проект. И, как я сказал в своем посте Запуск игровой студии без денег: деньги не совсем на моей стороне, тем более что этот пост не был полностью правдой. В общем, это больше похоже на Запуск игровой студии с меньшими затратами, чем без денег. Но это ни здесь, ни там.

И если вас не волнует, как мой проект связан с VCS (системами контроля версий), перейдите к концу, чтобы получить общие git «советы и хитрости, инструменты и утилиты».

Работа из командной строки

Прежде чем я продолжу - поскольку это будет иметь решающее значение для остальной части этой статьи - давайте поговорим об использовании командной строки для работы.

Примерно год назад я редко работал с командной строкой. Это всегда было крайним средством или для работы с проектами, которые были специально настроены для управления из командной строки. Мне просто нравятся мои графические интерфейсы. Что касается программирования, я бы ни на что не променял Visual Studio (хотя сейчас я обычно использую Visual Studio Code для работы, отличной от C ++ или C #).

Я действительно не знаю, что конкретно это изменило; возможно, именно терминал OS X или PowerShell сделали работу с командной строкой более удобной. А потом я обнаружил ConEmu, который сделал все еще более удобным для пользователя. А недавно, в ответ на мою статью о моих рекомендациях по программному обеспечению, один читатель рассказал мне о Cmder, который я теперь ни на что не променяю. Если только не найду что-нибудь получше.

А теперь, когда я привык работать в командной строке, я не мог рекомендовать это достаточно сильно. И нет, вы не должны впадать в крайности с его использованием; Я бы никогда не использовал текстовый редактор командной строки, я не использую его для всех своих задач и потребностей, и я бы определенно никогда не использовал его для создания ASCII-представления Joy Machine логотип.

Я также совершенно не помню всю гамму команд, которые я должен был бы выучить наизусть. Разнообразие флагов, которые может принимать данная команда, - это просто вещи, которые я не хочу занимать в моем мозгу - особенно команды PowerShell, которые следуют нетрадиционным стандартам, многословны, насколько это возможно, и, в общем просто тупой. То же самое и с командами git, которые, хотя я всегда помню основы, могут быть настолько безумно сложными, что я не хочу - кхм - зафиксировать их в памяти. Но для этого нужны псевдонимы git, но об этом позже. А пока вот некоторые ресурсы из общедоступного репозитория GitHub Joy Machine (каждая подпапка в корневой папке scripts имеет свой собственный README файл для подробностей, но я буду TL; DR здесь:

  • Улучшения терминала OS X: .inputrc файл для улучшения работы пользователей терминалов OS X. Это включает в себя заставку Ctrl + стрелки пропускать целые слова, завершение команд / папок без учета табуляции и т. Д. И т. Д. Источник этого файла - суть от Григория Николая, которого я не знаю, но очень ценю его существование.
  • Скрипты PowerShell - все это я, и я их обожаю. По большей части это различные псевдонимы для команд, которые я никогда не запомню, но использую часто. Однако образец профиля также сканирует подпапку cmdlets на предмет всех автономных сценариев PowerShell (любой команды с некоторой степенью сложности) и добавляет ее в ваш набор инструментов при каждой загрузке PowerShell. Ура!

Steel Hunters Контроль версий: первая итерация

Мне нравится мерзавец; это отличная система контроля версий с интуитивно понятным рабочим процессом и набором команд. Тем не менее, Perforce всегда был лучшим решением для игр, поскольку он невероятно хорошо обрабатывает двоичные файлы (особенно большие двоичные файлы). Я не большой поклонник графического интерфейса пользователя Perforce, но он работоспособен. При этом все сказано: мне нравится мерзавец. А у Perforce есть Helix4Git, который работает как со стандартным управлением версиями Perforce, так и с git. Он просто поддерживает две отдельные базы данных, которые он отражает в зависимости от вашего рабочего процесса.

Возможно, вы уже поняли, в чем проблема: он отражает содержимое вашего репозитория на вашем жестком диске. А поскольку у меня никогда не было денег на обновление до настольного компьютера, который я указывал в январе, мое место для хранения на моем ноутбуке для разработчиков очень дорого.

Это быстро сделало его невозможным.

Steel Hunters Контроль версий: вторая итерация

Хорошо, на этот раз мы перейдем к Perforce. Я установил сервер на Amazon AWS EC2, установил необходимые серверные компоненты Perforce, и все было в порядке.

За исключением того факта, что затраты на сервер Amazon AWS EC2 увеличиваются. Быстро. Особенно, если у вас есть проект, который в то время был 100 ГБ без какого-либо локального управления версиями. Стоимость серверного хранилища быстро росла.

А так как я работаю над Steel Hunters, и это приносит отрицательные деньги, у меня всегда была работа (теперь у меня есть контракт или два на денежные доллары). У меня просто не было времени заниматься обслуживанием серверов, помимо всего прочего. Также: я ничего не знаю об обслуживании серверов, поэтому всякий раз, когда мне нужно было что-то сделать, я попадал в кроличью нору Google с 50 открытыми вкладками Chrome, каждая из которых решала один аспект серии проблем, с которыми я имел дело.

So: no-go.

Steel Hunters Контроль версий: третья итерация

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

GitHub, хотя я люблю его больше, чем большинство сайтов в Интернете, имеет ограничение на размер поддерживаемых репозиториев. Это примерно 2 ГБ; так что я мог хранить на нем исходные файлы и ключевые файлы двоичного содержимого, но это все равно казалось рискованным.

So: no-go.

Steel Hunters Контроль версий: четвертая итерация

Кто-то в Твиттере рассказал мне об Assembla, и это прозвучало идеально. Поддержка проектов git и Perforce. ДА. ЖИЗНЬ БЫЛА ЗАКОНЧЕНА. Я мог хранить исходные файлы в git (который, как мне кажется, не имел ограничений по размеру) и файлы содержимого в Perforce (у которого было ограничение по размеру, но это сработало для меня).

Когда я начал добавлять в свою команду подрядчиков - подрядчиков, которые из-за какого-то чуда Вселенной (или просто будучи великими людьми) были готовы работать за бесплатный / отсроченный платеж - эта установка с двумя VCS сбивала с толку, ее было трудно настроить, сложно управлять должным образом, да и вообще просто плохое моджо.

Этому не способствовали некоторые проблемы, с которыми я столкнулся с самой Assembla; их настройку Perforce на самом деле было довольно сложно согласовать с обычной настройкой Perforce. Поддержка git на стороне сервера (включая git-LFS, которую я неохотно использовал после того, как мне сказали, что она была значительно улучшена с тех пор, как я ее последний раз использовал), не соответствовала последним выпускам git и git-lfs. И это привело к некоторым невероятно причудливым ошибкам, на которые требовалось довольно много времени и которые было трудно исправить.

So: no-go.

Steel Hunters Контроль версий: итерация пятая

Затем я попробовал Visual Studio Team Services; это была VCS на основе git, и у нее без ограничений на размер репозитория. Это также бесплатно, если вы не хотите закрепить какую-то непрерывную интеграцию на основе Azure или другие причуды. Я не поверил отсутствию ограничений по размеру, поэтому связался со службой поддержки и объяснил, что мой проект большой. Очень большой. Они сказали: да, без ограничений, не беспокойтесь. "И это бесплатно?" Да, для ваших целей это совершенно бесплатно.

Я использую VSTS последние пять месяцев без единой проблемы. Управление пользователями - это большая проблема, но это такая необычная задача, что я просто согласился с ней.

Проблема, с которой я столкнулся пару дней назад, не связана с VSTS. Это было здорово во всех отношениях, за исключением множества инструментов, утилит и интеграций, которые полностью зависят от использования GitHub. Я до сих пор активно рекомендую его для средних проектов.

Проблема заключалась в том, что на жестком диске не хватало места. И, поскольку я не умен, мне потребовалось всего пару дней назад, чтобы наконец запустить инструмент анализа дискового пространства (WinDirStat) на диске с моим репозиторием Steel Hunters.

Его объем составил 380 ГБ. Из них 140 ГБ - это сам проект, а 240 ГБ - сама .gitfolder.

На следующий день я потратил на то, чтобы пробовать все, что смог найти во всем Интернете, чтобы попытаться удалить в истории репозитория неактуальные большие файлы, используя команды на основе git, другие команды на основе git. , И даже BFG . Я думаю, что в итоге мне пришлось сбрить около 10–20 ГБ данных из папки .git. И когда я пытался протолкнуть переписанную историю в VSTS, не получилось. Каждый раз он терпел неудачу. И не было комбинации решений, которые я мог бы найти (в том числе и то, что на этой странице), которые заставили бы его не потерпеть неудачу.

Steel Hunters Контроль версий: теперь

Вчера я подошел к этой проблеме с совершенно другой точки зрения. git и git-lfs остаются моей любимой формой VCS, которая не требует затрат на Perforce.

Небольшое отступление о git-lfs

git-lfs теперь включен в установщик Windows для git, и это нигде не делается очевидным и может привести к нескольким установкам git-lfs в вашей системе.

Где был я…

Я хотел придерживаться git и git-lfs и, более того, хотел вернуться к использованию GitHub. Я купил несколько «пакетов» хранилища git-lfs на GitHub, что было не идеально, но это не собиралось убивать мой банковский счет (помимо другого аспекта этого плана ниже), так как я просто откажусь несколько приемов пищи в неделю. И я придумал новое решение для управления всей нашей проектной базой:

  • Steel Hunters Project - весь исходный код, уникальные библиотеки DLL (необходимые для создания аспектов проекта) и отдельные файлы содержимого (файлы данных игры и, с сегодняшнего утра, Файлы UMAP из-за важности управления версиями для них, несмотря на их большой размер). Ура, счастливый Трент. Снова на GitHub!
  • Joy Engine (кастомная вилка Unreal Engine 4). Он тоже будет размещен на GitHub, потому что никогда не был проблемным ребенком.
  • Steel Hunters Source Asset Files - этот репозиторий предназначен для управления файлами исходного содержимого, которые импортируются в проект Steel Hunters UE4. Сюда входят такие файлы, как PNG, TGA, PSD, FBX и т. Д. И т. Д. Эти файлы более важны для проекта, чем любой UASSET в игровом проекте, поэтому я обратился за дополнительными пакетами хранилища git-lfs, поскольку я хочу, чтобы они были версионированными. Их не так много и они не такие тяжелые, как папка с содержимым игрового проекта, поскольку эта папка содержит ряд пакетов ресурсов Unreal Engine, для которых я обычно не забочусь об экспорте исходных файлов, за исключением особых обстоятельств.

Steel Hunters Папка содержимого проекта

Это была дилемма, сложенная слонами на слонах, на гигантских кубах твердого свинца. В целом: большинство этих файлов содержимого не меняются с какой-либо частотой. И если они действительно меняются, это обычно довольно тривиальное изменение флага, свойства или незначительные правки. Поскольку я всегда отмечаю, какие изменения я вношу достаточно подробно в своих сообщениях о коммитах git, если что-то когда-нибудь пойдет не так, я действительно мог бы просто прочитать историю коммитов и при необходимости повторно внести изменения (путем загрузки исходного пакета ресурсов или повторный импорт исходного файла).

В итоге я пришел к следующему решению: корзина Amazon AWS S3 для синхронизации каталога содержимого Steel Hunters с каждым изменением любых файлов. Эта папка управляется с помощью инструмента, который отслеживает любые изменения в папке и синхронизирует их с корзиной S3.

Это абсолютно идеально? Нет. Однако для меня это наиболее эффективный по времени способ поддерживать проект до тех пор, пока он не получит должное финансирование, и я смогу привлечь команду и кого-то с большим опытом, чем я, в управлении серверами (что сделало бы переход на Perforce жизнеспособным вариант, если возникнет необходимость).

Поскольку вчера весь этот план был реализован, время покажет, насколько хорошо все получится.

Работа с git как Rockstar

Я не претендую на роль эксперта по git, но к этому моменту я настолько освоился с рабочим процессом, основанным на командной строке, и создал изрядное количество ярлыков, инструментов и утилит для повседневной работы. легко. И я не держу это в секрете.

Но сначала: приложения с графическим интерфейсом пользователя git всегда плохи. Всем им не хватает полного набора функций, которые вам действительно нужны для правильного управления репозиторием, например. Да и сами приложения просто… плохие.

  • SourceTree, например, следует избегать любой ценой. Я обнаружил, что он глючит, работает медленно, полностью лишен возможности справляться с большими проектами и вызывает разочарование. Я даже не собираюсь связывать его или выделять жирным шрифтом. Вот что я об этом думаю.
  • GitKraken когда-нибудь станет хорошим. Его просто еще нет. У него есть проблемы с большими проектами, его интерфейс, хотя и симпатичный, не интуитивно понятен, и в нем отсутствуют некоторые очень необходимые функции для правильного управления репозиторием. Как я уже сказал: я думаю, это многообещающе.
  • GitHub Desktop - электронное приложение, которое я нашел вчера вечером, и ... оно мне нравится? Я бы не стал использовать его для управления репозиторием или чем-то еще, но если я когда-нибудь захочу быстро проанализировать все различные локальные репозитории на моем компьютере, я могу открыть его, увидеть несколько быстрых различий, а затем закрыть.

Тем не менее: графические интерфейсы для выполнения операций сравнения и слияния абсолютно необходимы. И хотя P4Merge выполняет свою работу надлежащим образом, то, что вам действительно нужно, - это Beyond Compare. Просто поверь мне. Во-первых, Beyond Compare не только выполняет операции сравнения и слияния в репозиториях git, но также может выполнять операции сравнения папок / файлов и слияния даже для вещей, которые не управляются никаким контролем версий. Это замечательно.

Но просто работайте с командной строкой (кроме вещи diff / merge)

Я действительно не могу подчеркнуть, насколько полезна командная строка git (кстати, при установке в Windows убедитесь, что вы устанавливаете и bash, и стандартную совместимость с Windows). Он мощный, он дает вам всю необходимую информацию, он лучше информирует вас о том, что управляется git-lfs, а что нет, он позволяет вам легко выбирать, что вы включаете в данный коммит, и так далее и так далее.

Это не значит, что сразу станет понятно, как с ним работать, но именно поэтому у меня есть несколько полезных файлов в папке git репозитория Joy Machine, которые могут мне помочь:

  • README - Некоторая общая информация о том, что делают шаблоны, а также некоторая общая информация о git в помощь.
  • gitconfig - Множество псевдонимов, которые либо ускоряют выполнение обычных операций, либо псевдонимы для операций, выполнение которых совсем не тривиально. git state, git lard, git prettylog и git last - мои любимые.
  • Также: я добавил цвета вывода для некоторых операций git. Это было необходимо.
  • gitattributes - Правила для файлов, которые я хочу сохранить в текстовом виде (CPP / H / CS), и некоторые общие правила для файлов, которые я хочу обрабатывать с помощью git-lfs.
  • gitignore - Список файлов и расширений, которые я обычно игнорирую (сосредоточен на проектах UE4).

Вывод

И это моя история о контроле версий. плавник