- PVSM.RU - https://www.pvsm.ru -
Когда я познакомился с Mercurial, то все свои знания я почерпнул из статей Спольского (перевод на Хабре [1]), которые подробно описывают основные принципы работы Mercurial и ежедневную работу с ним. Долгое время я использовал Mercurial в пределах, которые не превышали объема этих статей. Наверно, для одиночного разработчика этого почти достаточно. Почти. Но Mercurial сегодня значительно шире и обладает возможностями допускающими редактирование истории изменений, наличие которых, в общем-то, не очевидно, хотя возможности эти достаточно ценны. А из комментариев к разным статьям по системам управления версиями видно, что многие разработчики об этих возможностях не знают. Ниже я хочу провести обзор ряда возможностей Mercurial связанных с изменением истории.
О чем пойдет речь:
Ежедневная работа Mercurial заключается в создании новых наборов изменений (они же ревизии). Любой набор, как только он создан, навеки прописывается в репозитории. Неважно полезен ли этот отдельный набор, или он часть никому не нужной тупиковой ветви развития, он сохраняется и копируется во все репозитории. По крайней мере, так выглядит Mercurial на первый взгляд. С другой стороны иногда бывает действительно нужно удалять или заменять наборы изменений. Поэтому в Mercurial появился ряд инструментов, которые могут изменять историю. Изменять ревизии, которые известны другим репозиториям считается опасно, поскольку эти ревизии могут использоваться в других репозиториях, скажем, быть родителями новых ветвей. Поэтому удаление ревизий никогда не затрагивает внешние репозитории. Удаление локально. При синхронизации все ревизии, которые вы удалили у себя, будут вновь затянуты и создадут путаницу. Поэтому замена истории в Mercurial — это действие локального характера, которое проводиться только в пределах изменений, которых никто кроме вас не видит. Mercurial пытается автоматически отслеживать публичность или приватность наборов изменений при помощи механизма фаз.
Каждый набор изменений принадлежит к одной из трех фаз:
Итак, когда мы создаем новый набор изменений при помощи hg commit, этот набор относится к фазе draft. Этот набор есть только у нас, однако, при первой возможности все изменения будут отправлены в общий репозиторий. Фаза при этом изменится на public. Если мы хотим пока работать локально, чтобы об изменения не публиковались, то мы можем отнести изменения явно к фазе secret. Тогда изменения будут оставаться в локальном репозитории до тех пор, пока мы явно не изменим фазу на draft или public.
Проверяется и изменяется фаза командой hg phase. К примеру, возьмем репозиторий, в котором есть только один набор изменений:
hg log
changeset: 0:adfd3246d8b4
tag: tip
user: Пользователь
date: Sat Nov 07 11:12:43 2015 +0300
summary: initial commit
Проверяем, какая сейчас фаза у набора изменений 0:
hg phase -r 0
0: draft
Чтобы изменить фазу к команде добавляется параметр –draft, --public или –secret (они же –d, -p, -s). Изменяем фазу на секретную:
hg phase --secret –-force -r 0
hg phase -r 0
0: secret
Обратите внимание, что для того, чтобы увеличить фазу (в направлении от публичной до секретной) нужно использовать ключ --force. Уменьшение фазы в обратном направлении всегда безопасно. Чаще всего нужно только помечать наборы изменений как секретные, либо возвращать их к фазе draft. Механизм фазы задуман таким образом, чтобы не требовать особого внимания пользователя. Напоминаю, что изменять наборы изменений можно, только если они не принадлежат к публичной фазе.
Наверное, каждому случалось через мгновение после коммита обнаруживать ошибку в сообщении или сталкиваться с тем, что только что созданный коммит сломал билд. Как раз для этих случаев команда hg commit имеет опцию amend. Когда используется эта опция вместо создания отдельного набора изменений, вносится коррекция в последний из наборов (точнее в текущий набор). Все настолько просто, что рассказывать нечего. Создаем коммит с ошибкой в текстовом описании:
hg commit -m "Првый коммит"
Замечаем оплошность и тут же исправляем ее:
hg commit -m "Первый коммит" --amend
saved backup bundle to D:workHabrhg1.hgstrip-backup/54b061ad6202-amend-backup.hg
Результат:
hg log
changeset: 0:88779cfe79c1
tag: tip
user: Пользователь
date: Sat Nov 07 11:12:43 2015 +0300
summary: Первый коммит
Изменяется не только описание. Можно вносить правки в исходники, и они добавятся в новый набор изменений. Из вывода команды можно заметить, что Mercurial сделал бакап, на случай если мы сделали какую-то глупость. Восстановить бакап можно командой hg unbundle. И еще добавлю: commit --amend работает только с наборами изменений, у которых нет дочерних элементов.
Для начала нужно ToroiseHg переключить режим фиксации. После этого кнопка «Фиксировать» получит название «Отмена» (Перевод сбивает с толку. По смыслу должно быть «Перефиксировать»). При ее нажатии будет запускаться commit --amend со всеми плюшами – можно изменить сообщение, можно исправить ошибки в файлах.
Commit --amend доступно всегда, а вот команды hg rebase и hg strip является стандартными расширениями, которые по умолчанию отключены. Чтобы включить расширения нужно добавить в файл Mercurial.ini (либо в файл .hg/hgrc, чтобы включить расширения только в отдельном репозитории) следующие строки:
[extensions]
rebase =
strip =
Команда strip удаляет ревизию и всех ее потомков из репозитория:
hg strip 8
saved backup bundle to D:workHabrhg0.hgstrip-backup/92f6544e0370-backup.hg
Забавно, что команда strip удаляет, но не подменяет историю, поэтому ее допускается использовать с наборами изменений любой фазы. Однако если удалить наборы, которые засветились в других репозиториях, то при следующем затягивании изменений все удаления восстановятся.
Понять команду Rebase проще всего из примеров. Основная задача rebase – превратить две различные ветви в линейную историю.
Пока мы работали над веткой X, Y, Z, во внешнем репозитории возникли ревизии D, E.
Поскольку чужие изменения мы трогать не можем, мы можем перебазировать свои. Результат должен быть таким:
Локальные наборы изменений X, Y и Z удаляются (сохраняются в .hg/strip-backup, а вместо них вставляются аналогичные наборы изменений X2, Y2, Z2).
Rеbase делается следующей командой:
hg rebase --source 4 --dest 8
saved backup bundle to D:workHabrhg0.hgstrip-backup/1ab1a1cc3d8d-backup.hg
Есть и другие варианты использования команды. Сокращенное написание команды:
hg rebase -s 4 -d 8
Использование --base вместо --source:
hg rebase --base 6 --dest 8
Когда применена опция --base, то Mercurial спускается от указанной ревизии до общего предка, за исключением самого общего предка. В нашем случае --base 6 означает то же, что и --source 4.
Если указать только одну из опций: base, source или dest, то вместо отсутствующего параметра используется текущая ревизия.
Опускаем опцию --dest, используем текущую ревизия в качестве dest.
hg up 8
hg rebase --source 4
Опускаем опции --source и --base, используем текущую ревизию в качестве base.
hg up 4
hg rebase --dest 8
Результат операции
Несколько сценариев использования из документации Mercurial.
Простое перемещение ветви:
hg rebase --dest E --base C.
Пунктом назначения не обязательно должна быть конечная ревизия:
hg rebase --dest D --base C.
Немного более сложная структура:
hg rebase --dest C --source D.
Набор изменений слияния F перестает существовать за ненадобностью.
hg rebase --dest I --source D
Ревизия H удаляется, это ревизия слияния, а в результате работы rebase все наборы и так уже содержат все нужные изменения.
hg rebase --dest I --source B
Удаляются ревизии слияния D и H.
hg rebase --dest B --source C
hg rebase --dest I --source G
Иногда все изменения нужно вместить в одну ревизию. Для этого у команды rebase есть опция --сollapse.
hg rebase --dest B --base E –collapse
Небольшая автоматизация, которая автоматически запускает rebase каждый раз при затягивании изменений. Результат стремиться к тому, чтобы все локальные изменения нарастились к затянутой снаружи ветке. Это не всегда срабатывает, но если срабатывает, то экономиться лишнее слияние.
hg shelve --name shelve_name_1
...
hg unshelve shelve_name_1
hg diff > somefile
hg revert –a
...
hg import –no-commit somefile
Автор: RedApe
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemy-upravleniya-versiyami/108623
Ссылки в тексте:
[1] перевод на Хабре: http://habrahabr.ru/post/108443
[2] Расширение MQ: https://www.mercurial-scm.org/wiki/MqExtension
[3] Расширение HistEdit: https://www.mercurial-scm.org/wiki/HisteditExtension
[4] Расширение RebaseIf: https://www.mercurial-scm.org/wiki/RebaseIfExtension
[5] Расширение Evolve: https://www.mercurial-scm.org/wiki/EvolveExtension
[6] Команда hg graft: https://selenic.com/hg/help/graft
[7] www.mercurial-scm.org/wiki/Phases: https://www.mercurial-scm.org/wiki/Phases
[8] www.mercurial-scm.org/wiki/RebaseExtension: https://www.mercurial-scm.org/wiki/RebaseExtension
[9] www.mercurial-scm.org/wiki/StripExtension: https://www.mercurial-scm.org/wiki/StripExtension
[10] thedustytome.com/2014/05/29/Mercurial-Rebase-with-TortoiseHg: http://thedustytome.com/2014/05/29/Mercurial-Rebase-with-TortoiseHg/
[11] zeroturnaround.com/rebellabs/nine-awesome-features-and-extensions-for-mercurial-hg: http://zeroturnaround.com/rebellabs/nine-awesome-features-and-extensions-for-mercurial-hg/
[12] Источник: http://habrahabr.ru/post/274877/
Нажмите здесь для печати.