D:\sideБлогСистемы контроля версий – кому это надо?

⚠️ Обращайте внимание на даты.
Этот блог больше не ведётся с 17 января 2023, и на тот момент с написания этой страницы (07.02.2014) прошло 8 лет.

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

Какие нынче есть простые языки, относящиеся к “серьёзным”… скажем, Lua. В нём, кажется, проект может состоять исключительно из *.lua-файлов. Итак, чтобы разработать сколько-нибудь большой проект на Lua, понадобится его разбить на несколько файлов. Возможно, много файлов.

На этом этапе разработчик наверняка воткнётся в типичную ситуацию: он внёс изменения и в результате что-то испортил. Чтобы решить возникшую проблему, ему понадобится уточнить, какие именно изменения он внёс по сравнению с работающей системой. Если дело было “только что” – есть шансы просто вспомнить. Но обычно это не так. Как вариант – система резервных копий. Но это не панацея, не очень удобно, да и места занимает много.

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

Ещё один интересный момент – разработка некоторой “фичи” для проекта при необходимости параллельно держать работоспособную версию. Вот здесь начинается ад, потому что в простейшем случае проект просто копируется, и изменения вносятся в копию. Где ад? Сразу после завершения – проблемы будут в случае, если в “рабочую” версию были внесены фиксы, а в “свежей” версии их ещё нет, зато есть нововведения. То есть, чтобы соединить две версии, вам придётся вспоминать, какие именно ошибки вы поправили и каким образом, и так переносить изменения в вашу “свежую” версию.

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

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

Для начала: всякий проект в системе контроля версий, вся история его изменений и различные его разветвления хранятся в специальном хранилище под названием “репозиторий”. Git хранит в папке с проектом только выбранную вами редакцию, а всё остальное лежит в скрытой папке .git, которую не стоит трогать лишний раз. Чтобы поставить проект под систему контроля версий, нужно создать репозиторий в его корне: самом “высоком” месте файловой системы. В Git это команда git init. После этого нужно добавить файлы, которые вы будете отслеживать. Не уверены – добавляйте всё, если это не будет занимать много памяти. Для этого команда: git add . (с точкой в конце, это важно). Так вы добавите в репозиторий все файлы, что находятся в папке, где сейчас вы.

Когда вы изменяете файлы с кодом, вы в какой-то момент приходите к состоянию, когда система работоспособна, хоть может и не на 100%. Или же думаете, что текущее состояние стоит сохранить. Тогда вы записываете текущее состояние, к примеру, так: git commit -a -m "Hello, Git!" ­– в переводе: “Git, запиши текущее состояние (commit) всех (-a) файлов с примечанием (-m) «Hello, Git!»”. Будут записываться изменения всех файлов, добавленных в репозиторий командой, указанной выше. Разработчики называют такие состояния “коммит”, аналогично английскому термину.

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

 Изменения клонированного репозитория можно легко отправить обратно на сервер, воспользовавшись git push. При этом отправится не только последнее состояние, но и все промежуточные, которых на сервере ещё нет. Дальнейшие возможности более полно описывают в книгах, поэтому я их только вскользь упомяну. Хотите больше – почитайте любую книгу о Git, например, вот эту:

• Можно воспользоваться git branch и начать отдельную ветку от текущего состояния проекта. Или просто параллельную, начинающуюся “нигде”. Сценарий надобности уже описывал выше.
• Две ветки или два состояния можно соединить в одно новое при помощи git merge. Однако, автоматически это не всегда выполнимо или идеально.
• Можно сравнить два состояния при помощи git diff. Будет показано, какие файлы изменились и как. К сожалению, это нормально работает только с текстовыми файлами, с прочими всё намного хуже. Даже не надейтесь применять её к файлам, которые в Блокноте выглядят, как странная каша из необычных закорючек.
• Можно вкладывать одни репозитории в другие с помощью git submodule. Вдруг у вас два проекта используют некие общие файлы, изменения в которых должны быть синхронными. Разумно их выделить отдельно.

Что касается GameMaker – из таких систем поддерживается только Subversion, и только в GameMaker: Studio. И Subversion, должен отметить, система довольно скучная, поскольку сильно опирается на сервер и “ветки” в ней реализованы скорее как костыли – кладутся в папку отдельно от “рабочей версии”. Хотя это всё зависит от того, как организовывать код, но это сказывается на лёгкости использования.

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

Studio использует принципиально иной формат, основанный на XML (.gmx), и каждый проект в таком формате разбивается на множество мелких файликов. Каждый ресурс и файл конфигурации имеет собственный файл, и большую их часть можно открыть любым текстовым редактором. Нельзя разве что сами ресурсы: картинки, звуки. Такой формат, впрочем, позволяет пользоваться любой системой контроля версий, наличие интеграции с ней не является обязательным условием. Я даже несколько своих сайтов держу в Git, а также начал пользоваться им же для проектов в GMS.

Так, на случай, если у кого-то возник вопрос “а куда эти команды вбивать?”, я использую клиент MSYSGit, предназначенный для работы в командной строке. Такие вещи, строго говоря, предназначены не для новичков, но как только у вас появляются проблемы, решаемые ими – возможно, вам уже пора несколько поднять мнение о себе и перейти на менее дружелюбные для “простых смертных” инструменты. Есть также клиент Github для Windows, но у меня он работает через пень-колоду: в командной строке чувствуется больше контроля.