Существует мнение, что системы управления версиями предназначены исключительно для команд профессиональных программистов и бесполезны при самостоятельной разработке. В этой статье я постараюсь объяснить, почему это не так.
Но, прежде всего несколько слов о самих системах управления версиями. Это программное обеспечение предназначено для облегчения работы с постоянно изменяющимися файлами. Оно обеспечивает возможность сохранения промежуточных состояний файлов, создания нескольких версий одного файла (или их набора), позволяет переносить изменения между различными версиями файлов, просматривать внесенные изменения и многое другое.
Самое главное достоинство таких систем состоит в том, что из них не может исчезнуть информация. Т.е. всегда можно вернуться к однажды сохраненной версии файла, независимо от того, какие изменения были в него внесены.
Рассмотрим простой пример. Допустим, вы делаете web страницу. Проект состоит из трех файлов (с разметкой, таблицей стилей и скриптами). На каком-то этапе вы получили приемлемый внешний вид, но решили немного поэкспериментировать. Естественно эти эксперименты затронут все три файла, причем изменения будут внесены в различные их части.
Чтобы сохранить текущую версию проекта, вы делаете копию его файлов и экспериментируете уже с ними. Через некоторое время у вас накапливается десяток таких копий. И тут… вы находите ошибку в скриптах. Естественно, исправить ее нужно во всех копиях. И начинается карусель: «открыть» — «найти» — «вставить» — «сохранить» — «закрыть» — «перейти в следующую папку» — «повтор».
Если вы работаете в команде (даже из двух человек), то количество таких ситуаций растет как снежный ком. Потому что сюда добавляются исправления, сделанные вашим напарником.
Именно для таких ситуаций и разработаны системы управления версиями. Принцип их работы довольно простой. Для хранения информации создается специальное хранилище (что-то вроде базы данных), в котором сохраняются все внесенные в файлы изменения. Естественно, сохранение происходит исключительно по вашему желанию, и возвращаться вы сможете только к сохраненным состояниям.
Если вы работаете в команде, и несколько человек попытаются сохранить один и тот же файл, но с различными изменениями, система выдаст сообщение о возникновении коллизии. В этом случае разработчики договариваются между собой, какие изменения оставить и вносят их в хранилище.
Но эта статья об использовании систем управления версий при индивидуальной разработке, поэтому проблемы команд мы здесь рассматривать не будем.
Думаю, теории достаточно, переходим к реализации.
Выбор системы контроля версий
На сегодняшний день существует множество таких систем как платных, так и бесплатных с открытым исходным кодом. Из бесплатных, наибольшее распространение получили CVS и Subversion. Последняя появилась значительно позже и изначально позиционировалась как замена CVS. В Subversion реализован ряд возможностей, отсутствующих в CVS, что делает ее более привлекательной для новых проектов.
Установка и настройка Subversion
Здесь все предельно просто. Качаете с официального сайта дистрибутив и запускаете инсталлятор.
После установки вы сможете работать… но только через консоль. Естественно, это позволяет детально изучить работу системы, но вводить каждый раз имена файлов… мягко говоря, не очень удобно 🙂 .
Поэтому советую сразу скачать какой-нибудь графический клиент для Subversion. Полный их список находится здесь.
Я пользовался двумя:
1) Subclipse – это плагин для Eclipse(http://www.eclipse.org/), т.е. для его использования нужна эта IDE.
2) TortoiseSVN – это более универсальная оболочка. Она встраивается в «Проводник» Windows. При этом к иконкам файлов добавляются значки, отображающие текущее состояние файла, а команды можно выполнять из контекстного меню.
Теперь нужно создать хранилище
Для этого создаем новую папку, например, e:\docs\svn.
И, находясь в этой папке, выполняем команду:
svnadmin create my_project
Эта операция создаст папку «e:\docs\svn\my_project» со служебными файлами хранилища.
Примечание. Если вы используете какой-нибудь клиент, ищите пункт Create Repository.
Перед отправкой файлов в хранилище очень желательно определиться со структурой проекта
Это, наверное, самый сложный этап для новичков (по себе знаю 🙂 ).
Чтобы не морочить вам голову теорией приведу пару примеров, которые должны подойти для небольших проектов.
Первый пример. Используем две папки:
trunk/ – для размещения законченной (стабильной) версии (ветки) проекта;
branches/ – эта папка будут использоваться для экспериментов, т.е. в ней вы будете создавать папки с экспериментальными версиями проекта. Если вы решите, что какая-нибудь из этих версий должна заменить основную, то просто перенесете ее в trunk.
Второй пример удобно использовать, если нужны две версии проекта, различающиеся только несколькими файлами. Например, вы создаете web сайт, использующий базу данных. Параметры подключения к этой базе на вашем компьютере и на сервере будут отличаться, но не изменять же их каждый раз вручную.
Тут удобно использовать три папки:
trunk/
branches/
trunk_for_server/ — копия папки trunk для сервера (отличаются только файлы с параметрами подключения).
Перед закачкой файлов на сервер вы просто «сливаете» нужные изменения из trunk в trunk_for_server.
Примечание. Оба приведенных примера это только возможные варианты. Вы можете придумать свою структуру.
Переходим к созданию выбранной структуры в хранилище
Для этого создаем временную папку, например, e:\temp, а в ней пустые папки, соответствующие выбранной структуре.
Например, если вы остановились на первом варианте:
e:\temp\trunk \branches
Теперь, находясь в папке «e:«, выполняем импорт этих папок в хранилище.
svn import temp file:///e:/docs/svn/my_project -m "Начальный импорт"
Удаляем e:\temp.
В следующей статье я покажу несколько приемов работы с созданным проектом.
Интересное
Панорамные лифты otis удобное средство передвижения и украшение современного здания.
