Если вы давно заинтересовались профессией 3D художника или хотите работать в GameDev, но не знаете, на кого учиться и кем вообще можно стать в этой сфере, то эта статья для вас. Тут мы подробно опишем, чем вам предстоит заниматься на позициях от пропс артиста до технического художника, а также расскажем, где всему этому можно быстро и качественно обучиться. Поехали! #статья@cgitems
GIT. SVN, CVS. Системы управления контролем версий

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

В работе бывает всякое, иногда необходимо откатить файлы до ранних версий, восстановить их, либо заменить. Когда речь идет об одном компьютере и одном человеке, то всё просто - это можно контролировать и делать вручную средствами Windows и проводника (и высокого уровня ответственности). Но когда речь идет о коллективе, особенно удаленном, ведь компьютеры сотрудников могут находиться даже на разных материках, в дело вступают системы управления версиями, или системы контроля версий (Version Control System, или VCS). Далее мы будем называть их СКВ для краткости.

Что такое системы контроля версий?

Это программное обеспечение, которое призвано обеспечить системное и прозрачное управление файловыми структурами проектов.

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

01_системы управления версиями_cgitems.ru.png Графический пример того, как работает система контроля версиями. В центре сервер, по краям пользователи, которые имеют к нему удаленный доступ

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

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

Когда речь заходит о СКВ, то обычно подразумеваются программисты и совместная работа с кодом, но давайте внесем справедливости и рассмотрим эти процессы на уровне 3D художника. Нет смысла вдаваться в дебри, поэтому, по возможности, обобщим и упростим информацию для более легкого усвоения. Нам важна сама суть работы с системами и понимание того, как они участвуют в ежедневной работе 3D художника. Это важная информация, т.к. при работе в студии вы обязательно столкнетесь с такими системами, и их понимание будет хорошим преимуществом.

Виды систем контроля версий

Существует два общих вида систем контроля версий - централизованные и распределенные.

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

Суть двух видов систем в следующем:

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

02_системы управления версиями_cgitems.ru.png Централизованная система контроля версиями

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

03_системы управления версиями_cgitems.ru.png Распределенная система контроля версиями

Рассмотрим несколько основных и известных систем двух типов:

Первая и самая старая это CVS, которая была разработана в 80х программистом Диком Груном. Она является централизованной. Собственно, включает в себя все функции описанные выше - хранение и доступ к данным.

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

Ещё одна популярная и значительно более молодая централизованная система это Subversion, или SVN, разработанная в 2000 году компанией CollabNet. Она во многом аналогична CVS, и по сути была разработана как более совершенный аналог, исправляющий недостатки CVS. Также она предлагает более эффективные алгоритмы хранения информации.

Следующая система это GIT. Разработана в 2005 году Линусом Торвальдсом - создателем операционной системы Linux. Её основное отличие заключается в том, что эта система распределенная. Считается что она является одной из самых быстрых систем, но при этом существует мнение о том, что она сложнее для понимания по сравнению, например, с SVN.

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

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

Как уже упоминалось ранее - основные принципы взаимодействия у всех систем управления версиями являются типовыми, так как все они призваны выполнять одну и ту же функцию. Давайте разберемся с основными этапами и командами для работы с ними.

Общий принцип работы с системами управления версиями

Изначально СКВ это набор команд и типов реакций на эти команды. Делается это при помощи командной строки. Разные СКВ могут иметь свои специфические команды, особенности настроек, условия взаимодействия между пользователями. Но в основе своей любая система управления версиями имеет общий порядок работы.

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

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

Подход к работе

Рассмотрим подход к работе с учетом того, что у вас установлен клиент для работы с репозиториями.

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

Часто бывает так, что помимо основной рабочей копии создается её дубликат - некий эталон, по которому программа может определить изменения в проекте от последнего обновления без обращения к серверу. Этот дубликат называется Fork.

04_системы управления версиями_cgitems.ru.png Наглядный пример клонирования проекта с сервера (скачивание репозитория)

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

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

Обновление репозитория

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

Во избежание проблем и для поддержания актуальности версии существует такая команда как Update, Fetch, или Pull (есть некоторая разница между Fetch и Pull, она заключается в том что первая не сливает ветки, а вторая делает это по умолчанию. Это касается систем контроля версий GIT). Она позволяет обновить проект и это стоит делать по возможности как можно чаще, особенно при ежедневной активной работе над разработкой.

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

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

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

Ещё одно примечание - некоторые интерфейсы систем контроля версий позволяют отметить, какие файлы вы хотите обновить. Это позволяет экономить время и не брать те части проекта, которые не нужны вам в данный момент.

Модификация проекта

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

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

Фиксация изменений (Commit)

Собственно, когда вы выполнили этапы работы, или всю задачу поставленную перед вами, настает этап фиксации. Эта команда называется Commit - так называемая контрольная точка.

Она позволяет зафиксировать внесенные изменения в локальной копии репозитория. Эти изменения могут копиться одно за другим образуя последовательность, или цепочку изменений. Эта функция позволяет поэтапно отследить изменения файлов и, к примеру, при необходимости откатиться.

Следующая команда это Push. Выполняя её, вы передаете на сервер в основной репозиторий изменения прошедшие Commit, сохраняете рабочий процесс и делаете его доступным для других разработчиков.

05_системы управления версиями_cgitems.ru.png Графический пример работы пользователя/сотрудника с общими файлами проекта через сервер и его команды Commit и Push

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

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

Ветки проекта (Branch)

Ещё существует такое понятие как ветвление, или Branch - от единого проекта можно вывести отдельную ветку изменений в каком-то конкретном участке проекта и работать с ней не затрагивая весь проект целиком.

Commit и Push ветки будут затрагивать только её файлы, но не основной репозиторий. В дальнейшем можно произвести слияние этой ветки с основным проектом и зафиксировать изменения, либо перевести её в отдельный проект.
Например - пока программисты работают над текущей сборкой проекта в своей ветке, дизайнеры и 3D художники могут работать над новой локацией, которая войдет в следующую сборку.
Они будут делать это в своей ветке, следовательно, их изменения не затронут ветку программистов и не войдут в текущую сборку, что исключит конфликты и поломки. В дальнейшем её можно либо откатить, либо слить с основной веткой проекта.

Merge

Слияние (Merge) это проверка изменений основного и локального репозиториев и их слияние в новую версию на основе зафиксированных изменений. Это общее понятие объединяющее вышеописанные этапы.

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

Конфликты изменений

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

Причины могут быть самыми разными, один из примеров - вы сделали Commit изменений, но не сделали Push. Либо не забрали какие либо изменения связанные с текущей работой, при попытке обновить репозиторий эти изменения могут вызвать конфликт.
В целом это очень ситуационно, и суть здесь в том, что если система не справилась с обновлением, либо отправкой изменений, то она выдаст оповещение и, в зависимости от клиента(оболочки), предложит варианты решения, либо укажет на источник ошибки. Далее вам надо будет либо найти причину и решить её, либо просто произвести откат проекта до последней неконфликтной точки.

Блокировка проекта или его части

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

Это нужно для того, чтобы не нарушилась целостность его работы и ничего не сломалось. Например – Level Designer может занять целую локацию и заблокировать её для чужих изменений на время своей работы. В процессе заблокированные файлы проекта будут доступны другим участникам только в режиме чтения.
В разных системах это реализовано несколько по-разному, но суть одна - файл будет заблокирован, а система будет отслеживать и извещать разработчиков об этом.

Помимо описанных функций каждая СКВ может иметь свои дополнительные возможности и команды. Это очистка файлов, разные виды проверок репозитория, разные способы откатов. Часто могут быть индивидуальные решения, для разрешения конфликтов изменений и обновлений.

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

Итак, мы прошлись по основным принципам и понятиям работы с системами контроля версий.

Как уже говорилось - в целом все гораздо глубже и сложнее, но на деле вы, как 3D художник, будете сталкиваться только с основными этапами - подключение к проекту и загрузка репозитория, ежедневные манипуляции, такие как своевременное обновление проекта и фиксация ваших изменений.
В любой студии всегда есть специалист, который занимается поддержкой и обслуживанием таких систем. Его задача сделать так, чтобы все системы работали правильно, а сотрудники имели необходимые инструкции для взаимодействия с системой контроля версиями.
В первую очередь вы 3D художник и ваша задача - производить контент. Но понимание основ работы с СКВ облегчит вам жизнь и поможет перестать бояться их, так как на деле все просто и рутинно.

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

Популярные клиенты (оболочки) для работы с системами контроля версий

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

Но что делать тем, кто далек от таких тонких материй? Установить себе клиент с графической оболочкой, которая сводит все функционалы СКВ до набора понятных кнопок и меню.
Разработчики, работающие над СКВ прекрасно понимают, что далеко не всегда есть необходимость в глубокой работе с системами и заучивании всех команд. Такое решение нас полностью устраивает.
Все программы такого типа объединяет понятие GUI - Graphical User Interface, или графический интерфейс пользователя. Давайте пройдемся по самым популярным клиентам, которые с большой вероятностью могут встретиться вам на пути при работе в игровых студиях.

Github Desktop

Сама по себе система контроля версиями GIT является, пожалуй, самой популярной системой в мире. Она признана специалистами и рядовыми пользователями как быстрая, понятная и доступная. Применяется на широком спектре проектов совершенно разного уровня. Также её выделяет большое и живое комьюнити и большой набор инструментов для работы с этой системой.

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

06_системы управления версиями_cgitems.ru.png GIThub Desktop

Это пример интерфейса программы. Как видите, в ней есть понятное и чёткое разделение функций - списки изменений и истории, возможность выбрать репозиторий, его ветку, если таковая имеется и кнопка для работы с фиксацией и загрузкой проекта.

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

TortoiseGit/SVN/CVS

Еще один GUI клиент, который существует для всех актуальных СКВ. Вы уже знаете, в чем их сходство и различие. Суть все та же - удобная работа с репозиториями.

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

07_системы управления версиями_cgitems.ru.png Tortoise

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

Справа представлен интерфейс программы для работы со списками файлов при обновлении и фиксации проекта.

Rabbit VCS

Еще существует аналог Tortoise для Linux. По сути это тоже самое, просто для другой платформы, часто разработчики выбирают его как более удобное и быстрое решение, упомянем его просто чтобы указать на то, что не только на Windows существуют подобные решения (хотя для кодеров это разумеется очевидно, но мы здесь занимаемся моделированием и саморазвитием).

08_системы управления версиями_cgitems.ru.png Rabbit VCS

Smart SVN

Ещё один клиент, в этот раз конкретно для SVN системы. В среде программистов, по ряду мнений, считается более быстрым и удобным в сравнении с Tortoise. Опять же упомянем его просто чтобы подчеркнуть разнообразие решений.

09_системы управления версиями_cgitems.ru.png Smart SVN

Versions

Ещё один часто упоминаемый клиент для системы SVN предназначенный для работы на Mac.

10_системы управления версиями_cgitems.ru.png Versions

Заключение

Собственно, этот список можно продолжать бесконечно, наверняка компетентный программист сможет сказать почему, например, надо выбрать именно SmartSVN а не Tortoise, или почему GIT самый популярный. Или напротив, почему GIT не стоит применять.

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

Почти наверняка вам не придётся столкнуться с подавляющим большинством программ, но их обилие говорит о том, что это очень востребованное направление в области работы с данными. Т.к. профессия 3D художника является важной частью разработки игр (и не только игр), то просто надо понимать, что рано или поздно вы столкнетесь с необходимостью работы с системами контроля версиями. А понимание общих принципов того, как они функционируют, позволит вам легче влиться в рабочий процесс и сосредоточиться на самом важном - создании качественного контента.

11_системы управления версиями_cgitems.ru.png
Ваша заявка отправлена!
Если во входящих на почте: нет письма, проверьте папку спам или напишите нам в телеграм