Хочу в геймдев!

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

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

Рис. 16. Схема SVN

Commit – сохранение, фиксация (в архиве, репозитарии и др.) изменений в программном коде. Update – сверка текущей версии кода у сотрудника с версией в репозитории и обновление её в случае наличия более новых файлов на сервере.

Работа с GIT выглядит так: есть удаленный репозиторий, локальный репозиторий и рабочая копия. Это значит, что появляется один дополнительный по сравнению с SVN шаг – синхронизация локального репозитория с удаленным. Это дает большое преимущество – возможность работать сразу над несколькими задачами. Пока изменения, которые вы вносите, находятся в промежуточном состоянии и могут «сломать» версию, они сохраняются в локальном репозитории, не создавая проблем остальным. Так что сотрудник может в любой момент вернуться к выполнению задачи.

Допустим, мы работаем над чем-то рискованным: например, решили поменять всю игровую физику. Чтобы не мешать остальным сотрудникам, имеет смысл создать отдельную ветку. Ветка – это последовательность изменений, параллельная ветка репозитория. Она не влияет на главную версию, так что сотрудники могут работать над своими задачами одновременно, не боясь что-то сломать.

Рис. 17. Схема Git

Дизайнеры и художники могут, например, спокойно работать в основной ветке, а программисты – в своей. Во многих студиях существует правило: «Одна задача – одна ветка», что позволяет экономить время на тестировании вносимых изменений.

В SVN тоже можно создать отдельные ветки, только в общем репозитории. Но Git позволяет работать с ветками гораздо быстрее и удобнее.

Когда все будет протестировано и принято, изменения можно будет внести в основной проект.

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

Continuous Integration, то есть практика разработки, при которой рабочие копии постоянно сливаются в основную ветку, предполагает, что никто не работает «в стол», а как можно быстрее отдает свою работу в общий проект. При таком подходе версия игры не должна собираться раз в месяц, все должно быть собрано хотя бы за последние пару дней. Живая версия, в которую сотрудники могут поиграть, интегрируется непрерывно, чтобы вовремя отследить возможные проблемы.

Если накатывается много изменений, чтобы версия была стабильна, обычно договариваются о времени отсечки. Скажем, все изменения, внесенные после 17:00, не попадут в завтрашнюю версию. Таким образом, если обнаружатся какие-то проблемы, сегодня еще будет время для их устранения, и все сотрудники на следующий день получат рабочий билд, в который можно играть.

По сути, работа в системе контроля версий для рядовых сотрудников – это несколько операций: забрать из репозитория данные, отправить обратно свои изменения или сменить ветку и, если нужно, посмотреть работу других специалистов. Для новичков все это может выглядеть довольно страшно, но в большинстве случаев хватает рабочего дня, чтобы более или менее разобраться, что к чему, и приступить к работе.

С точки зрения администратора, есть еще одна важная задача: решить, где, собственно, будет храниться репозиторий. Первое решение – личный компьютер. Это самый простой вариант, и его часто используют разработчики, работающие с Git, из-за логики локальных репозиториев, позволяющей никому не платить и работать, даже когда общий удаленный репозиторий по тем или иным причинам недоступен.

Второй вариант: поставить или арендовать отдельный компьютер под сервер, например, того же Git, который будет заниматься только этим; так делают почти все крупные компании. Это безопасно, никто извне не сможет посмотреть или получить информацию, но обычно дороже, чем другие варианты.