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

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

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

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

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

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

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

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

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

Рассмотрим, что представляют собой ветви. Ветвление — это процесс создания веток кода из главной ветви. Это позволяет разработчикам вносить свои изменения в код, не отправляя их основную базу. Используя ветви, разработчикам не нужно хранить полную историю файлов на одном сервере. Вместо этого они могут вести полную историю изменений кода с течением времени. Затем система контроля версий может объединить эти отдельные ветви обратно в главную ветвь. Если разработчик не готов к объединению, он может передавать свои изменения в отдельную ветвь, а затем по мере готовности объединить ее с главной ветвью.

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

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

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

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

Централизованные системы контроля версий используют рабочий процесс на основе чекина/выгрузки для подключения к главному серверу. Все изменения или обновления исходного кода автоматически сохраняются в репозитории как новая версия. Централизованные системы контроля версий поддерживают мощные возможности ветвления и слияния, не требующие клонирования репозитория на несколько компьютеров. В этом смысле она более безопасна. Для работы централизованным системам контроля версий требуется подключение к сети. Так как команды привязаны к одной версии проекта, которая хранится на одном сервере, сбой сервиса может существенно замедлить работу. Другой недостаток централизованных систем контроля версий — их плохая масштабируемость. Чем больше разработчиков работают над проектом, тем меньше возможностей выгружать изменения в стабильную среду, что может вызвать такие проблемы, как конфликты при слиянии. Если вам нужна система контроля версий, которую легко настроить и использовать, то вы можете выбрать централизованную систему.

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