GameMaker: Использование внешних систем управления версиями

За годы, я наблюдал отдельный сценарий слишком много раз:

Человек демонстрирует полное нежелание исследования принципов работы системы контроля версий, будь то из-за "отсутствия нужды" или утверждений о том, что текущие подходы (обычно, ручное копирование) достаточны или даже превосходны.
Человек теряет дни, недели, или даже месяца работы из-за собственных, аппаратных, или программных ошибок.
Несмотря на заметную горечь о происшедшем, человек пытается продолжать защищать свою позицию.

Поскольку пояснять данные вещи "в индивидуальном порядке" не слишком рационально, я решил написать запись, что покрывала бы наиболее важные элементы:

Пояснение преимуществ систем управления версиями над обычным резервным копированием.
Пояснение (пошаговая инструкция) принципов использования стандартной комбинации для контроля версий - BitBucket (сервис) + Git (ПО) + SourceTree (визуальный клиент).

Данная статья преимущественно направлена на пользователей GameMaker: Studio, но может быть с легкостью применена к другим инструментам.

Преимущества

Размер: Обычная резервная копия (без урезания её частей) занимает столько же места, как сам проект. С системами управления версиями, с другой стороны, для каждой ревизии записываются лишь изменения файлов, так что, если вы изменили 1КБ кода, то "коммит" (правка) для этих изменений займет приблизительно 1КБ.
Организация: В резервную копию могут быть включены примечания о правках. Система управления версиями позволяет просматривать, какие файлы были изменены в правке, когда, и даже просмотреть, когда последний раз редактировалась отдельная строка кода в каком-либо из файлов.
Так же спасает от скопления массы неоднородно подписанных файлов по мере развития проекта.
Надежность: Пожалуй, самая распространенная ошибка при резервном копировании - сохранение копий на тот же диск, где лежит проект, означая, что в случае аппаратной ошибки пропадет и проект, и его резервные копии.
Другая распространенная ошибка - сохранение всех резервных копий на внешнем SSD. SSD выходят из строя быстрее чем HDD, и по своей концепции ориентированы больше на скорость работы, чем долговечность. А потеря резервных копий - весьма серьёзная потеря. Особенно, в случае неисправностей в рабочей копии.
Системы управления версий позволяют автоматически (и весьма быстро - см. размер) синхронизировать правки с удаленным сервером (или серверами), и существует некоторое количество сервисов для гарантирования того, что ваши файлы "просто так" никуда пропасть не смогут.
Контроль версий: Частично связано с пунктом 1 - из-за соображений использования места на диске, обычно не рационально хранить каждую резервную копию игры, означая, что старые или "менее значимые" копии должны будут быть рано или поздно удалены. Системы управления версиями позволяют откатить проект до состояния на момент любой из правок.
Совместная разработка: Системы управления версиями позволяют не заниматься передачей и ручным совмещением измененных файлов - над проектом может работать произвольное количество человек за раз, и слияние правок производится подавляюще автоматически.

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

Так что, приступим - вам понадобится лишь способность читать и немного времени.

Создание репозитория

В начале, нужно создать где-то репозиторий для проекта.
Зачастую используют GitHub, BitBucket, или GitLab.
GitHub чаще используют для публичных проектов из-за популярности и социального функционала. BitBucket и GitLab чаще используют для приватных проектов из-за наличия бесплатных планов для приватных проектов.
Ради примера будет использован BitBucket.

Так что, проследуйте на BitBucket, создайте учетную запись (или войдите в существующую), и выберите "Репозитории - Создать репозиторий" в меню сверху (или нажмите сюда). Откроется страница с формой, назначение полей которой следующее:

Имя репозитория: Собственно, название проекта для отображения в списке проектов.
"Это приватный репозиторий": Определяет, будет ли проект приватным (доступ по приглашениям), или публичным (кто угодно может просматривать).
Тип репозитория: определяет систему управления версиями, что будет использована.
Люди часто спорят о том, какая система лучше, но в контексте данной записи это особого значения не имеет.
Описание: Отображается на сайте. Для приватных репозиториев особой роли не играет.
Трекер задач: Включает баг-трекер\трекер задач - позволяет создавать задачи\рапорты для отслеживания текущих целей. Помогает с координацией для командных проектов, но может быть полезным и для одиночных проектов.
Вики: Включает возможность создания и заполнения страниц документации по проекту. Для приватных проектов обычно не особо нужно.
Язык: Определяет изначальные настройки репозитория, преимущественно для исключения временных файлов.
На момент написания этой записи, у BitBucket нет отдельной настройки для проектов на GameMaker, так что данную опцию можно оставить на значении по умолчанию.

В общем-то говоря, можно заполнить лишь "Имя репозитория" и нажать "Создать репозиторий". И, вуаля - у вас теперь есть репозиторий для проекта.

Настройка программы для контроля версий

Следующим шагом является установка ПО, что позволило бы вам удобно работать с репозиторием(ями). BitBucket активно предлагает SourceTree, что сделан той же компанией:

SourceTree свои функции выполняет. Программа не пытается подсвечивать синтаксис как GitHub Desktop или GitKraken, но это так же означает что она использует меньше ресурсов, и не начинает громко кашлять во время просмотра правки с тысячей измененных файлов.

Клонирование репозитория

Теперь, когда у вас есть программа и пустой репозиторий, самое время "клонировать" (скачать) его и заполнить файлами.
Если вы выбрали BitBucket и SourceTree, для этого нужно лишь нажать на кнопку "Clone in SourceTree".
Иначе вам нужно будет взять URL репозитория (в BitBucket имеет формат https://Name@bitbucket.org/Name/RepName.git и показывается в правом верхнем углу страницы) и открыть диалог клонирования репозитория в программе.

Данный диалог выглядит следующим образом (с небольшими различиями зависимо от программы):

Cloning a git repository for use with GameMaker: Studio

Единственная важная настройка тут - "Destination Path", что определяет, куда будут скачаны (и откуда будут обновляться) файлы.

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

После нажатия на "Clone" и нескольких секунд ожидания, у вас появится папка репозитория, что будет содержать или ничего вовсе (помимо скрытой папки .git, что содержит историю правок и прочие данные), или несколько шаблонных файлов (.gitignore, readme.md). Репозиторий так же будет отображен в списке программы.

Первый коммит

Теперь, когда репозиторий синхронизирован между сервером, диском, и программой, настало время непосредственной загрузки файлов в него.

В начале, вы перемещаете файлы проекта в папку репозитория.

После, вы открываете репозиторий проекта в программе. В SourceTree это делается двойным нажатием мыши на проекте в меню слева.

Открывается вкладка репозитория, в которой можно наблюдать несколько вещей, наиболее важная из которых - список измененных файлов (в SourceTree - в вкладке File Status). Поскольку репозиторий ещё ничего не содержит, все добавленные в него файлы считаются измененными:

Тут же можно задать, какие файлы не будут хранится в репозитории.

Чтобы исключить местоположение, нажмите правой кнопкой мыши на файл в списке, и выберите "Ignore...". Это отобразит небольшое окошко, уточняющее, нужно ли "игнорировать" лишь один этот файл, все файлы такого типа в папке, или всю папку.

Так же стоит заметить что "игнорирование" файлов не равносильно их удалению - файл останется на диске (и будет доступен), но его изменения не будут отслеживаться (и, следовательно, синхронизироваться). Так что, в случае скачивания репозитория (другими людьми\с другого устройства), игнорируемые файлы нужно будет добавить вручную, если они имеют какое-то значение.

Для GameMaker'а, обычно есть смысл исключать лишь sound/audio, что содержит WAV/MP3/OGG версии звуков, поскольку, по мере накопления правок, нередко оказывается, что звуки занимают подавляющее количество места несмотря на сомнительную выгоду сохранения их правок вовсе (поскольку импортируемые звуки обычно не являются исходными).

Так же стоит заметить, что исключение путей добавляет строки в файл .gitignore, что так же может быть отредактирован вручную для удобства или отмены исключения файлов (что сложнее проделать через программы, поскольку вы сами попросили их не показывать эти файлы).

Когда вы закончили выбирать файлы для включения в репозиторий, нажмите на галочку возле "Unstaged files" (или выберите все файлы и нажмите пробел) для включения их в "коммит" (правку).

После, вы вводите описание правки, ставите галочку на "Push changes immediately to ..." (для отправки на сервер сразу после внесения правки в локальную копию), и нажимаете на кнопку "Commit" ниже (так же можно нажать Ctrl+Enter). Это создает правку, начинает загрузку файлов на сервер, и загруженные файлы можно будет наблюдать в веб-версии сервиса как только загрузка будет завершена.

Внесение правок

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

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

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

Так что вы можете рассмотреть изменения, сгруппировать их в одну или более правку (используя галочки на файлах вместо общей наверху), или вовсе отменить изменения (выбрав "Discard" из контекстного меню файла).

Аналогично, когда файлы выбраны, вы вводите описание правки, нажимаете Commit, и правка заносится (и отправляется на сервер, если галочка была поставлена).

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

Просмотр правок

Если вам нужно пересмотреть свои прошедшие изменения, это можно сделать в вкладке "Log / History".

Тут можно выбирать отдельные правки и файлы в них для просмотра изменений:

Если есть необходимость откатить проект до состояния отдельной правки, это можно сделать с помощью пункта "Reset current branch to this commit" в контекстном меню правки. Одно лишь примечание - желательно перед этим внести правкой какие-либо новые изменения, дабы не перепутывать файлы из разных точек времени.

Совместная работа

Если вы создали приватный репозиторий, права доступа пользователей к нему выдаются в исключительном порядке.

В BitBucket'е для этого есть среднего размера кнопка справа:

Так что вы нажимаете на нее, вводите адреса электронной почты, устанавливаете права доступа, и нажимаете на кнопку для отправки приглашений.

Когда люди приняли приглашения, они могут клонировать репозиторий (что уже содержит проект), и аналогично с ним работать.

После внесения изменений другими людьми, они могут быть скачаны с помощью кнопки "Pull" в программе.

Кнопка "Fetch", с другой стороны, проверит на наличие изменений и скачает их, но не применит их к локальной копии автоматически.

По умолчанию, большая часть программ проверяет репозитории на предмет наличия обновлений раз в 10-15 минут. Если вам известно, что правки были внесены, выбор Pull/Fetch перепроверит репозиторий на наличие новых правок.

Если одни и те же строки в файлах не были одновременно изменены двумя независимыми правками, слияние изменений происходит гладко и автоматически.
Если же данный инцидент всё же произошел, вам нужно будет либо отменить свои изменения и применить их "поверх" отдельной правкой, либо посмотреть документацию по слиянию веток (англ. branch merging").

Итоги

Несмотря на то, что ознакомление с системами управления версий занимает небольшое количество времени, последующие операции занимают значительно меньше времени\усилий, и долгосрочные преимущества с верхом покрывают затраченное на изучения время.

Если я что-то пропустил, спрашивайте в комментариях.

Удачи!