Открыта запись на курс Vehicles and Props Старт обучения 28 ноября 2024 Преимущества курса: - разбор домашних работ только автором курса; - справедливые фидбеки каждую неделю; - помощь в выполнении тестового задания при трудоустройстве; - рекомендации в топовые студии в РФ при успешном прохождении курса.
GIT и SVN. Различия и особенности

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

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

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

На данный момент наиболее популярными программными оболочками являются: GitHub, GitLab, TortoiseSVN. Они основаны на двух разных системах: Git и SVN.

SVN и Git: особенности и различия

SVN (сокращение от Subversion) - открытое программное обеспечение, система контроля версий, выпущенная в 2004 году и призванная заменить морально устаревшие к тому времени системы CVS, исправив ошибки, распространенные проблемы и недостатки функционала. Пик популярности SVN пришелся на 2010-е годы, однако к 2016 стал снижаться.

Git - система, созданная автором Linux Линусом Торвальдсом и впервые выпущенная в 2005 году. В отличие от SVN, Git имеет принципиально новую архитектуру и подход к работе.

Системы контроля версий SVN (Subversion) и Git выполняют одну и ту же задачу: обеспечивают совместную работу нескольких пользователей над общими проектами и отслеживают изменения в них. При этом, в своем устройстве и принципах работы они имеют несколько различий:

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

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

Во-вторых, Git - более современная система, имеющая гибкие инструменты для ветвления и слияния проекта. Git имеет бОльшую скорость выполнения операций и представлен несколькими популярными программами-оболочками, такими как GitHub и GitLab, предоставляющими удобный доступ к функциям Git. Несмотря на конкуренцию с Git, SVN также не теряет популярности благодаря своим особенностям и функционалу. Наиболее популярный клиент, основанный на архитектуре SVN - TortoiseSVN.

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

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

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

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

Репозиторий на Git

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

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

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

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

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

SVN/GIT Схема работы распределенной системы Git. Пользователи обмениваются изменениями друг с другом и с центральным репозиторием, находящимся на сервере.

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

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

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

  • В системе Git файлы, находящиеся под контролем версий, могут находится в трех состояниях:
    • Изменен (modified). В такой файл были внесены изменения в процессе работы, но эти изменения еще не были никак зафиксированы;
    • Индексирован (staged). Такой файл со всеми его изменениями уже отмечен для последующей фиксации.
    • Зафиксирован (committed). Такой измененный файл зафиксирован в репозитории и все изменения сохранены. Собственно, любая фиксация изменений в репозитории называется коммитом, причем не только в Git, но также и в SVN.

Проекты Git состоят из трех основных сегментов: рабочей копии, области индексирования и непосредственно каталога Git.

SVN/GIT Схема сегментов Git и их взаимодействия

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

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

Каталог Git непосредственно хранит все метаданные и объекты проекта. Именно эта часть переносится на компьютеры других пользователей при клонировании репозитория.

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

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

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

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

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

Репозиторий на SVN

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

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

SVN/GIT Централизованная система SVN. В отличие от Git, в системе SVN на клиентских компьютерах находятся только рабочие копии данных из единого для всех пользователей хранилища.

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

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

SVN/GIT Схематическое представление ревизий в SVN. Каждое новое состояние репозитория фиксируется со следующим порядковым номером ревизии. Исходное состояние репозитория имеет номер ревизии 0

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

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

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

Фиксация и обнародование изменений выполняется с помощью команды “Commit”. Процесс актуализации рабочей копии в соответствии с последней ревизией запускается командой “Update”.

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

Программная оболочка добавляет функции Subversion прямо в контекстное меню проводника Windows, что делает систему интуитивно понятной.
Работа с отдельными файлами без затрагивания всего репозитория и функция блокировки занятых в работе файлов позволяют избежать конфликтов. В зависимости от специфики проекта, SVN системы могут быть даже удобнее чем Git, а также SVN кушает гораздо более объемные файлы чем Git.

Заключение

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

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