В этой статье я продолжу рассказ об использовании Subversion – одной из самых популярных на сегодняшний день систем контроля версий.
В этот раз речь пойдет об использовании нескольких веток разработки.
Прежде всего, разберем, в какой ситуации может понадобиться несколько веток. Вариантов множество, но подробно анализировать мы их не будем, а просто рассмотрим конкретный пример.
Допустим, вы закончили разработку первой версии web приложения (или просто сайта). Теперь нужно перенести его на сервер хостера. В большинстве случаев при этом придется изменить параметры подключения к базе данных, отключить вывод подробного описания ошибок, profiling и т.п. Скорее всего, эти изменения затронут несколько файлов.
После отправки файлов на сервер, вы решили продолжить работу над проектом. Для этого, все настройки необходимо вернуть в исходное состояние. И так каждый раз при обновлении приложения на сервере. Думаю, никому не нужно объяснять, что это очень не удобно и может привести к ошибкам.
Как раз в этом случае нам и пригодится возможность Subversion создавать параллельные ветки разработки.
Идея простая. Создаем ветку для серверной версии проекта. Вносим в нее необходимые изменения и «заливаем» файлы на сервер. После этого переключаемся на основную ветку (файлы с настройками возвращаются в исходное состояние) и продолжаем разработку.
Одно из основных достоинств веток Subversion в том, что можно «сливать» любые изменения из одной ветки в другую. Таким образом, мы можем внести в ветку для сервера изменения из основной ветки так, что параметры подключения к БД останутся неизменными.
После переноса изменений нам останется только скопировать обновленные файлы на сервер.
Теперь рассмотрим конкретный пример.
Допустим, в репозитории проекта мы создали две папки:
trunk – для основной ветки разработки;
branches – для дополнительных веток.
Примечание. О том, как это сделать можно прочитать в статье «Эффективное управление проектами (Subversion)».
На данный момент проект в рабочем состоянии и находится в папке trunk.
Как мы и говорили, создаем новую ветку, в папке branches. В прошлой статье я немного рассказывал о ветках и переключении между ними, поэтому сейчас напомню только основные моменты.
Команда
svn copy file:///path_to_project/trunk
file:///path_to_project/brunches/web
-m “Ветка для размещения проекта на сервере”
создаст новую ветку разработки, которая будет размещена в папке brunches/web репозитория.
Примечание. При создании новой ветки настоящего копирования файлов не происходит. Это предотвращает черезмерное увеличение репозитория. Тем не менее, с точки зрения пользователя работа с веткой ничем не отличается от работы с настоящей копией.
Переключаемся на созданную ветку
svn switch file:///path_to_project/brunches/web
Эта команда создаст рабочую копию ветки.
Вносим в нее любые изменения (например, меняем параметры подключения к базе данных) и выполняем команду commit (т.е. сохраняем изменения в репозитории).
Очень важно писать осмысленные комментарии при сохранении данных, т.к. по ним придется ориентироваться в различиях между ветками. Фразы вроде «Все пофиксил» или «Куча мелких исправлений» не говорят ни о чем.
Теперь переключаемся на trunk
svn switch file:///path_to_project/trunk
И продолжаем работу.
В какой-то момент мы нашли и исправили ошибку в одном из файлов проекта. Теперь нужно исправить эту же ошибку на сервере. При этом в файл, который содержал ошибку, были внесены экспериментальные изменения, которые не должны попасть на сервер.
Т.е. нам нужно «слить» часть изменений из одной ветки в другую.
Прежде всего, нужно четко знать номера ревизий, которые содержат нужные изменения. Тут как раз и пригодятся созданные комментарии.
Посмотреть историю изменений можно с помощью команды
svn log
Она выведет список ревизий с комментариями. С помощью дополнительных параметров этой команды можно ограничить список:
svn log --stop-on-copy – выводит перечень ревизий между последней и ближайшей, в которой была выполнена операция копирования (создания ветки)
svn log -r 100:200 – список изменений между ревизиями 100 и 200
svn log -r 100:HEAD – между ревизией 100 и последней ревизией проекта.
Допустим, мы выяснили, что нужные нам изменения сделаны в ревизиях 205 и 206 основной ветки проекта.
Теперь переключаемся на ветку brunches/web
svn switch file:///path_to_project/brunches/web
И выполняем слияние
svn merge -r 205:206 file:///path_to_project/trunk
Эта команда выполнит слияние изменений из ревизий 205 и 206 ветки trunc в текущую папку (на данный момент в этой папке находится рабочая копия ветки brunches/web).
Теперь можно зафиксировать изменения ветки brunches/web в репозитории с помощью команды commit и скопировать исправленную версию приложения на сервер.
Очень важно. При выполнении команды commit обязательно в комментарии укажите номера ревизий, из которых взяты изменения (например, «изменения из trunk -r 205:206»). Это позволит избежать повторного копирования этих изменений в дальнейшем.
После этого, можно опять переключаться на основную ветку (trunk) и продолжать разработку.
Как видите, все довольно просто, а главное – удобно.
Примечание. Вам не обязательно использовать командную строку. Существует множество графических клиентов для Subversion, которые предоставляют удобный доступ к командам. Например, TortoiseSVN или Subclipse.
Заключение
Эта статья не является руководством по использованию веток, я просто привел пример их использования, который, на мой взгляд, удачно отражает их преимущества. Причем пример ориентирован на индивидуальных разработчиков или команды из двух-трех человек. Если вы хотите серьезно использовать Subversion при разработке, советую почитать книгу Управление версиями в Subversion. Это полное руководство об этой замечательной системе управления версиями.
Удачи!
