Контроль версий проекта в Mercurial

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

Mercurial – распределенная система контроля версий. Крайне удобный и полезный инструмент в разработке. Как и любая другая VCS, Mercurial хранит историю изменения вашего проекта и позволяет откатывать все внесенные изменения до зафиксированного ранее состояния. При этом Mercurial обладает рядом преимуществ перед некоторыми другими системами контроля версий:

• Во-первых, это открытая система, что в первом приближении означает ее бесплатность.

• Во-вторых, Mercurial хранит достаточно информации об изменениях, чтобы процесс создания и слияния веток был безболезненным.

• Ну и, в-третьих, это распределенная система, что избавляет вас от необходимости иметь единый сервер с репозиторием (но никто не запрещает таковой организовать, просто введя некоторые правила в использование системы).  

Разумеется, на этом преимущества использования Mercurial не заканчиваются, но лично мне достаточно и этих трех пунктов, чтобы однозначно сделать выбор в пользу Mercurial.

Правила нумерования версий системы

Я придерживаюсь следующего правила нумерования версии проекта:

Версия системы нумеруется тремя целыми числами разделенными точкой: X.Y.Z

• X – мажорный номер версии проекта. Инкрементируется в случае существенного изменения в системе, заметного конечному пользователю. Обратная совместимость нарушается.  До завершения работы над первой стабильной версией проекта, мажорный номер принять за 0
• Y – минорный номер версии проекта. Инкрементируется при серьезных исправлениях или добавлении в проект новой функциональности. Обратная совместимость может нарушаться.
• Z – второй минорный номер версии проекта. Инкрементируется при исправлении ошибок. Обратная совместимость не нарушается.

При изменении мажорного номера минорные номера обнуляются. При изменении первого минорного номера второй минорный номер обнуляется.

Стандартный рабочий цикл с VCS

Если вы не знакомы с системами контроля версий, рекомендую ознакомиться со статьей на Wikipedia (как минимум той ее частью, в которой описаны основные термины). И прочитать этот цикл статей на habrahabr.ru.
Стандартный рабочий цикл с VCS достаточно подробно и полно описан в Wikipedia:

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

1. Любые рабочие, тестовые или демонстрационные версии проекта собираются только из репозитория системы. «Персональные» сборки, включающие ещё не зафиксированные изменения, могут делать только разработчики для целей промежуточного тестирования. Таким образом, гарантируется, что репозиторий содержит всё необходимое для создания рабочей версии проекта.
2. Текущая версия главной ветви всегда корректна. Не допускается фиксация в главной ветви неполных или не прошедших хотя бы предварительное тестирования изменений. В любой момент сборка проекта, проведённая из текущей версии, должна быть успешной.
3. Любое значимое изменение должно оформляться как отдельная ветвь. Промежуточные результаты работы разработчика фиксируются в эту ветвь. После завершения работы над изменением ветвь объединяется со стволом. Исключения допускаются только для мелких изменений, работа над которыми ведётся одним разработчиком в течение не более чем одного рабочего дня.
4. Версии проекта помечаются тэгами. Выделенная и помеченная тэгом версия более никогда не изменяется.

Требования к конвенции по работе с VCS

Главная задача системы контроля версии заключается в предоставлении возможности комфортной работы над проектом команде разработчиков. Разработчики должны иметь возможность получить в любой момент времени копию интересующей их версии проекта в стабильном состоянии. А так же, свободно создавать и закрывать ветки по их усмотрению.

Конвенция работы с Mercurial на основе именованных веток 

Интерпретируя и адаптируя приведенное выше к условиям работы именно с Mercurial, можно предложить следующую схему работы:

1. Принять конвенцию о существовании центрального репозитория. Т.е. создать репозиторий на сервере и договориться считать его ревизии актуальными. Под каждый новый проект создавать директорию и инициировать в ней такой «центральный» репозиторий.

hg init

2. При создании репозитория в нем находится единственная ветвь с именем default. Эту ветвь принять за ветку для разработки. Так как главная ветвь содержит только стабильные версии проекта, ее необходимо создать при завершении работ над первой стабильной версией проекта, или сразу при создании репозитория. Ревизии в главной ветке пополняются только за счет объединения ее с ветками разработки. Т.е. изменений в ней проводиться не должно.
   
3. При завершении работы над первой стабильной версией проекта создается главная ветвь (*обычно я называю ее releases)

hg branch <Имя Главной ветки>

4. В главную ветвь добавляется тег с номером 1.0.0 (до этого нумерация начиналась с нулевого мажорного номера).

hg tag 1.0.0

 Все дальнейшие изменения разрабатываются в отдельных ветках и по завершении цикла разработки отдельные ветки сливаются с главной. Судьба дефолтной ветки остается на ваше усмотрение.
5. При обнаружении ошибок или при добавлении новой функциональности в проект (или инициировании долгосрочной  работы над проектом) в главном репозитории создается новая именованная ветвь. Имя ветки формируется по вашему усмотрению. Не стоит именовать ветку, присваивая ей номер версии, т.к. возможна ситуация, когда будет создана новая ветка с большим номером и работы над ней завершатся ранее, чем в ветке вами создаваемой.

hg branch <Имя ветки>

6. При завершении работы над новой функциональностью или после исправления ошибок, основная ветка сливается с веткой для разработки, после чего последняя закрывается.

hg commit --close-branch –m “<Имя ветки> is closed”
hg update <Имя Главной ветки>
hg merge tip

А к главной ветке добавляется тег с номером новой версией.


hg tag <x.y.z>

Предложенная стратегия не претендует на уникальность, но на мой взгляд является достаточно простой в понимании и гибкой в применении.

Базовый набор команд необходимых при работе с Mercurial

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

• Создавать новый центральный репозиторий

hg init – создает репозиторий в текущей директории

• Копировать центральный репозиторий в свою рабочую директорию

hg clone <Адресс центрального репозитория> - клонирует репозиторий в текущую директорию

• Создавать новые именованные ветки

hg branch <Имя ветки> - создает новую ветку и присваивает ей имя

• Уметь ориентироваться в структуре репозитория

hg branches – покажет все существующие ветки
hg branch – покажет ветку, в которой находится рабочая копия
hg heads – покажет головные ревизии существующих веток

• Менять рабочую директорию (перемещаться между ветками)

hg update <Имя ветки> - обновит рабочую директорию до состояния, зафиксированного в головной ревизии указанной ветки
 

• Выполнять слияние веток

hg merge <Имя ветки> - выполнит слияние текущей ревизии с головной ревизией указанной ветки

• Добавлять теги

hg tag <Имя тега> - добавляет ярлык к текущей ветке

• Фиксировать внесенные изменения

hg commit – фиксирует внесенные изменения

• Получать изменения из главного репозитория и публиковать в него собственные изменения

hg pull – вытягивает изменения из репозитория
hg push – отправляет зафиксированные изменения на сервер

Разумеется, это не полный перечень команд необходимых для комфортной работы с Mercurial. Для получения большей информации используйте

hg help