Версии под контролем

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

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

Subversion достаточно молодая система, изначально нацеленная на замену CVS (Concurrent Versions System), которая является самой известной и распространенной системой контроля версий. Дистрибутив Subversion и всю необходимую документацию можно найти на сайте разработчиков.

Чтобы двигаться дальше, необходимо определиться с терминами и понятиями, используемыми в Subversion:

* Хранилище (Repository). Это место централизованного хранения данных. Хранилище располагается на сервере и представлено в виде дерева файлов.
* Правка (Revision). Это состояние хранилища в определенные моменты времени. Процесс создания правки называется «Фиксация». Каждая правка имеет номер, который присваивается при фиксации.
* Ветка (Branch). Это направление разработки, существующее независимо от других направлений, но имеющее общую с ними историю. Фактически представляет собой копию проекта (или его части) в определенный момент времени и совокупности фиксаций изменений. Чаще всего ветки используются для хранения различных релизов проекта. Кроме этого ветки могут применяться для изоляции группы правок, которые могут нарушить работоспособность всего кода.
* Рабочая копия (Working Copy). Это копия хранилища (или его части) на рабочем месте пользователя.

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

* /trunk — основная ветка разработки. В ней ведется большая часть разработки: внедряются новые функции, исправляются ошибки.
* /branches — различные ветки. Здесь могут храниться предыдущие стабильные релизы или располагаться наборы исправлений, решающие какую либо определенную задачу. В общем, в этом каталоге хранятся все ветки, кроме /trunk.
* /tags — различные метки. Меткой называется поименованная правка. Физически представляет собой простую копию части хранилища в определенный момент времени. В отличие от ветки, в метку нельзя выполнять фиксацию, т.е. изменять ее. Наиболее часто метки используются для обозначения релизов проекта.

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

В качестве иллюстрации приёмов работы с Subversion, ниже приведены два примера такой работы.

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

Простейший рабочий цикл при использовании Subversion выглядит следующим образом:

1. Обновление рабочей копии. Этот шаг необходим для приведения рабочей копии в актуальное состояние.
2. Внесение изменений. Этот шаг является основным в работе. На этом шаге вносятся изменения в файлы и/или в структуру файлов проекта.
3. Анализ изменений. Этот шаг служит для контроля сделанных изменений перед фиксацией их в хранилище.
4. Слияние изменений, выполненных другими, со своей рабочей копией. Этот шаг нужен для гарантии, что нет конфликтов между локальными изменениями и изменениями других разработчиков
5. Фиксация изменений. Этот шаг служит для сохранения изменений рабочей копии в хранилище. Таким образом, изменения, сделанные одним человеком, становятся доступны всем участникам проекта.

Далее каждый шаг будет рассмотрен более подробно.

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

Шаг 2. Иван решил добавить возможность регистрации пользователей. Для этого он создал новый класс /classes/user.class.php и пустой каталог для модуля /modules/user/. Василий стал расширять функциональность модуля публикации новостей, добавляя свойство "категория" к объекту "новость". А Сергей, исправляя ошибку в модуле публикации статей, обнаружил, что такая же ошибка есть и в модуле новостей, и решил ее тоже исправить.

Сергей и Василий стали редактировать соответствующие файлы в своих любимых редакторах, а Ивану пришлось совершить несколько дополнительных действий. А именно, создав файл класса и пустой каталог в каталоге модулей, Иван указал Subversion, что этот файл и каталог нужно взять под версионный контроль. Сделал он это командами
svn add user.class.php
svn add user

Теперь файл user.class.php и каталог /modules/user/ взяты Subversion «на заметку» и при следующей фиксации попадут в хранилище. Если бы в каталоге user/ были бы файлы, они тоже попали бы в хранилище.

Шаг 3. Каждый из программистов, после того как закончил свою часть работы, выполнил команду svn status и убедился, что все изменения выполнил правильно.

Если после выполнения команд svn status и svn diff обнаруживается, что изменения некоторых файлов ошибочны, следует выполнить команду svn revert. Это отменит некоторые (или все) изменения и вернет указанные файлы в состояние после последней синхронизации с хранилищем.

Шаг 4. Сергей первый закончил свою работу. Он проверил правильность всех изменений, выполнил команду svn update и убедился, что конфликтов с хранилищем нет. После этого он зафиксировал свои изменения и переключился на другую задачу, начав рабочий цикл снова.

Через некоторое время Василий тоже закончил свою работу. Выполнив слияние, он обнаружил, что его изменения файла news.php конфликтуют с недавно сохраненным исправлением Сергея. Клиент Subversion Василию не только сообщил о конфликте, но и создал 3 файла (news.php.mine, news.php.r15, news.php.r16), а также пометил конфликтное место в файле news.php таким образом:

Маркеры конфликта

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

Для решения этой проблемы Василий посмотрел лог-сообщение к правке #16 (номер конфликтной правки указан в последнем маркере) и узнал, кто делал эту правку. После разговора с Сергеем, Василий внес необходимые коррективы в файл (и удалил маркеры, за этим нужно следить вручную) и выполнил команду svn resolved. После чего перешел к фиксации изменений.

У Ивана ничего особенного при слиянии не произошло, и он перешел к следующему шагу.

Шаг 5. После слияния изменений, каждый из разработчиков лучшей CMS выполнил команду svn commit, т.е. зафиксировал свои изменения в хранилище.

Если бы Василий не выполнил команду svn update, а сразу попытался бы зафиксировать свои изменения, то команда svn commit была бы отклонена с сообщением об устаревшем файле news.php.

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

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

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

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

Василий, для того чтобы тратить как можно меньше времени на сопровождение разных версий своего форума, с самого начала проекта разделил версии проекта на несколько "веток". В соответствии с рекомендациями, выложенную на сервер версию форума Василий поместил в ветку /branches/on_server, версию с новой функциональностью перенес в ветку /trunk, а новую версию форума с полностью переписанным ядром поместил в ветку /branches/2_x.

Таким образом, если Василию нужно исправить ошибку в эксплуатирующейся версии форума, он рабочую копию берет из ветки /branches/on_server. А если решил поработать над новым ядром, то из каталога /branches/2_x. При этом большую часть работы Василий выполняет с веткой /trunk: добавляет новые функции, изменяет работу старых, исправляет найденные ошибки.

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

Когда Василий решает, что достаточно отладил новую версию форума и ее можно ввести в эксплуатацию, он переносит текущее состояние ветки /trunk на сервер, копирует /trunk в /branches/on_server и создает метку с текущим номером релиза, например, /tag/release-1.3.

Внедрение системы контроля версий в процесс разработки веб-проекта позволяет снизить трудозатраты и решить ряд организационных проблем, как команде программистов, так и программисту-одиночке. Однако область применения Subversion не ограничивается программированием. Вот несколько задач, решение которых удобно с помощью Subversion: написание документации командой авторов (особенно географически распределенной), разработка и сопровождение сайта, состоящего только из статичных html-страниц.

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

Статьи по теме

Капитан грузового судна, или Как начать использовать Docker в своих проектах

Рассказываем, что такое Docker, как его использовать, а также пробежимся по сильным сторонам, терминологии и установке инструмента. Docker я...

2024-11-26

Что такое сторителлинг: техники и примеры

Разберем работающие техники сторителлинга: Путь героя, Сила конфликта, Мономиф, Спарклайны, Гора, Фальстарт и Рамка или «Лепестки»...

2024-07-24

Виджеты для веб-сайтов: влияние кнопок на продажи

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

2020-11-30

CRM: что это и как помогает бизнесу?

CRM: что это и как помогает бизнесу? Представители бизнеса − независимо от его направленности − сталкиваются с необходимостью взаимоде...

2020-11-30

Картинки на сайте: как правильно работать с атрибутами Alt и Title

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

2018-03-27

Доменные имена: всё, что о них нужно знать

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

2018-03-21

Яндекс.Вебмастер: как с ним работать?

Яндекс.Вебмастер − это специальный сервис, который открывает массу возможностей для специалистов по работе с сайтами. Помимо функциона...

2017-12-12

Разработка сайта для муниципальной организации в Хабаровске

Благодаря собственному сайту появляется прекрасная возможность для двустороннего общения с клиентами. Такая форма общения значитель�...

2016-11-30

Домен второго уровня: для чего он нужен?

  Домен или доменное имя по сути представляет собой буквенную последовательность, которая обозначает имя интернет-ресурса. Также в до�...

2016-11-22

Форма обратной связи на сайте: значение и виды

  Одной из функций сайта является его общение с посетителями. Делать это ресурс может с помощью форм обратной связи. Если таковая на пл�...

2016-10-28

Вебвизор: для чего он нужен и как его получить?

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

2016-10-19

Контент-анализ: в поиске релевантных страниц

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

2016-08-30

Как выбрать исполнителя для создания сайта?

  Рано или поздно перед руководителем практически каждой компании встаёт вопрос создания сайта. Вариант с самостоятельными попытками...

2016-08-17

Битые ссылки: что это и как от них избавиться?

  Одной из бед сайтов являются битые ссылки. Что они собой представляют? Линки, которые ведут на несуществующую страницу. В этом случае ...

2016-08-10

Особенности подбора ключевых слов для SEO-текстов

  Для успешного продвижения сайта его необходимо наполнять SEO-оптимизированными текстами. Их основное отличие от обычных информацион�...

2016-07-06