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

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

Чаще всего в качестве элементов для контроля версий выступают:

ѕ файлы;

ѕ директории;

ѕ hard — и softlinks.

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

Типовые примеры веток таковы:

контроль версия программный продукт.

ѕ ветка для запроса на изменения — заводится для версий, создаваемых в ходе работы по запросу на изменение («девелоперская», или «сиарная», ветка);

ѕ интеграционная ветка — служит промежуточным хранилищем для процесса стабилизации;

ѕ релизная ветка — для выкладывания версий при стабилизации конфигурации (см. соответствующий раздел первой части статьи). Какие-то версии на ветке могут быть в дальнейшем объявлены частью базовой конфигурации;

ѕ отладочная («дебажная») ветка — для кратковременного хранения версий, в основном, для целей проверки каких-либо решений.

Рисунок 1 — Дерево версий элемента element. c.

На рисунке 1 изображен пример дерева версий. У файла element. c создана релизная ветка release₁. x, куда складываются стабилизированные версии этого элемента (1−5). Для сохранения дельты по каждому запросу на изменения заводится отдельная ветка со специальным форматом имени. В нашем случае формат имеет вид rec_, где номер_записи — это ID запроса на изменение в системе отслеживания. Для объединения дельты от разных разработчиков создаются интеграционные ветки с названиями вида int__, где суффикс хранит описание интеграции или номер стабилизируемой конфигурации. Также можно увидеть ветку для отладки, чаще всего они именуются как dbg__ - на неё выкладываются проверочные варианты изменений.

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

Для этого используется механизм слияния версий. Как правило, он подразумевает создание новой версии элемента, для которой в качестве основы берется базовая версия на выбранной ветке (база), и к ней применяются изменения, содержащиеся в выбранной сторонней версии (источнике). В англоязычных источниках используется термин merge («мёрж»). Ветка с версией-источником может быть отращена как от версии-источника, так и от его более ранних предков. Существующие СКВ позволяют делать слияние как вручную, так и автоматически. Причем второй способ является основным. Ручное слияние запрашивается лишь в случае конфликтов.

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

К вопросу об общих предках и о слиянии изменений: кроме ручного и автоматического, слияние может быть произведено двухпозиционным и трёхпозиционным способом. Двухпозиционное слияние производится простым сравнением двух версий и сложением их дельты (разницы между версиями элемента). Алгоритм работает по принципу diff’а или приближенно к нему: взять дельту и вставить/удалить/изменить нужные строки.

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

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

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

Самые известные системы контроля версий, которые чаще всего упоминаются — CVS, Subversion, Git, Mercurial, Bazaar и Monotone.

Все эти системы объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом.