CC BY
454
№ 5'2015 ВЕСТНИК МГУП ИМЕНИ ИВАНА ФЕДОРОВА © Московский государственный университет печати имени Ивана Федорова
ISSN ON-LINE 2409-6652 _vestnik.mgup.ru
УДК 004.023
СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ
Шурыгин Владимир Николаевич
профессор кафедры информатики и информационных технологий, кандидат технических наук, доцент Московский государственный университет печати имени Ивана Федорова 127550 Россия, г. Москва, ул. Прянишникова, д. 2А schurygin@yandex. ги
Сиваченко Даниил Андреевич
студент Института принтмедиа и информационных технологий Московский государственный университет печати имени Ивана Федорова 127550 Россия, г. Москва, ул. Прянишникова, д. 2А Шиевг[email protected]
Аннотация. Рассматриваются основные виды СКВ, особенности их устройства и организация работы проекта при их использовании.
Ключевые слова: VCS, локальные системы контроля версий, централизованные системы контроля версий, децентрализованные системы контроля версий, master, develop, ветви функциональностей, ветви исправлений.
Система контроля версий (от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое. Под системой контроля версий понимается механизм сохранения промежуточных состояний кода разрабатываемого программного обеспечения. То есть с помощью этой системы программист может управлять своими файлами во времени: смотреть историю изменений файлов и каталогов, возвращаться к более ранним версиям кода, объединять несколько версий файла [1]. Основной областью применения контроля версий является коллективная разработка чего-либо (чаще всего это программы, но область применения программированием не ограничивается). Однако и для разработчика-одиночки контроль версий может быть полезен. Такие системы наиболее широко используются при разработке программного обеспечения для хранения исходных кодов разрабатываемой программы. Однако они могут с успехом применяться и в других областях, в которых ведется работа с большим количеством непрерывно изменяющихся электронных документов. В частности, системы управления версиями применяются в САПР, обычно в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления (Software Configuration Management Tools). В данной работе рассматриваются основные виды СКВ, особенности их устройства и организация работы проекта при их использовании.
Виды СКВ[2]. Условно СКВ можно разделить на три типа:
• локальные системы контроля версий;
• централизованные системы контроля версий;
• децентрализованные системы контроля версий.
Локальные системы контроля версий — сервер
СКВ, содержащийся непосредственно на рабочей станции пользователя. Часто для контроля версий своего проекта применяется простое копирование файлов проекта в отдельную директорию. Данный подход очень распространен из -за его простоты, однако он подвержен появлению ошибок. Можно легко забыть, в какой директории вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. Для того чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи обо всех изменениях в файлах, осуществляя тем самым контроль ревизий. Пример: утилита RCS, которая входит в состав Developer Tools на MacOSX.
Централизованные системы контроля версий — СКВ в которой основной репозиторий проекта хранится на отдельном сервере. В данной схеме становится легче синхронизировать работу участников проекта. Однако при отказе сервера теряется история нововведений разработчиков. Примеры централизованных СКВ: CVS, Subversion, Perforce.
Децентрализованные системы контроля версий — СКВ, которые позволяют клиенту полностью хранить у себя копию репозитория проекта. После внесения изменений в подобный репозиторий его можно соединять с основной веткой разработки на сервере. В этом случае, если один из серверов, через который разработчики обменивались данными, выйдет из строя, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэка-пом всех данных.
Модели ветвления [3]. СКВ разрешает вести работу над проектом сразу нескольким разработчикам, позволяя создавать отдельные ветки разработки проекта.
№ 5'2015 ВЕСТНИК МГУП ИМЕНИ ИВАНА ФЕДОРОВА © Московский государственный университет печати имени Ивана Федорова
Условно в проекте можно выделить несколько типов веток разработки.
Главные ветви: Ветвь master, Ветвь develop.
Ветвь master создается при инициализации репози-тория. Мы считаем ветку origin/master главной. То есть исходный код в ней должен находиться в состоянии production-ready в любой произвольный момент времени. Ветвь origin/develop мы считаем главной ветвью для разработки. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза. Эту ветку также можно назвать интеграционной. Она служит источником для сборки автоматических ночных билдов. Когда исходный код в ветви разработки (develop) достигает стабильного состояния и готов к релизу, все изменения должны быть определенным способом влиты в главную ветвь (master).
Вспомогательные ветви:
• ветви функциональности (feature branches);
• ветви исправлений (hotfix branches).
Ветви функциональностей (featurebranches), также называемые иногда тематическими ветвями (topicbranches), используются для разработки новых функций, которые должны появиться в текущем или будущем релизах.
ISSN ON-LINE 2409-6652 _vestnik.mgup.ru
Ветви для исправлений (hotfixbranches) порождаются необходимостью немедленно исправить нежелательное поведение производственной версии продукта. Когда в производственной версии находится баг, требующий немедленного исправления, из соответствующего данной версии тега главной ветви (master) порождается новая ветвь для работы над исправлением. Смысл существования данной ветки состоит в том, что работа команды над ветвью разработки (develop) может спокойно продолжаться, в то время как кто-то один готовит быстрое исправление производственной версии.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. A successful Git branching model [Электронный ресурс]. — URL: http://nvie.com/posts/a-successful-git-branching-model (датаобращения: 15.11.2015)
2. Scott Chacon. Pro Git / Scott Chacon, Ben Straub. — New York: Apress, 2009. 598 p.
3. Susan Potter. Архитектура приложений с открытым исходным кодом / Susan Potter — New York: O'Reilly, 2013.
VERSION CONTROL SYSTEM
Vladimir Nikolayevich Shurigin
Moscow State University of Printing Arts 127550Russia, Moscow, Pryanishnikova st., 2A
Daniil Andreyevich Sivachenko
Moscow State University of Printing Arts 127550Russia, Moscow, Pryanishnikova st., 2A
Annotation. The paper considers the main types of VCS, especially their equipment and organization of the project in their use.
Keywords: VCS, local Version Control Systems, centralized version control system, decentralized version control system, master, develop, feature branches, hotfix branches.
