Это четвертая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:
Одно из главных преимуществ Mercurial состоит в том, что вы можете использовать личные клоны репозитория для экспериментов и разработки новых возможностей. Если что-то пошло не так, можно все исправить за мгновение.
Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное:
Emacs, как же я тебя люблю. Как бы то ни было, все можно исправить. Наиболее распространённым способом справиться с такими проблемами является использование команды
Эта команда вернет файлы в именно то состояние, что было у них в момент последнего коммита. Mercurial не любит что-либо удалять, так что вместо того чтобы затереть рецепт на свинском латинском, он переименовал файл:
А что если все зашло слишком далеко и вы уже закоммитили?
Есть команда
Представьте, что вы хотите поставить большой эксперимент в свободное время. Ваш босс нанял нового дизайнера, Джима. С тех пор дизайны, которые вы получаете, стали просто абсурдны. В них кислотный зеленый текст, ничего не выровнено (на это есть «художественные» причины, ага) и юзабилити хромает. Вы хотите прийти на работу в выходной и все переделать, но боитесь коммитить свои изменения, так как не уверены на 100%, что ваши идеи лучше, чем у этого рехнувшегося дизайнера. Джим курит траву практически все время с момента пробуждения до момента отхода ко сну. Вы не хотите использовать это против него, да и все думают, что эта привычка никого не касается до тех пор, пока дизайны в порядке. Но всему есть предел. Так ведь? И дизайны у Джима не в порядке, и вообще он дерзкий какой-то.
При работе с Mercurial вы можете просто создать клон всего репозитория:
Это не настолько расточительно, как может показаться. Так как в репозиториях recipes и recipes-experiment хранится одно и то же (пока), то Mercurial воспользуется "жёсткими ссылками" (hard links). А значит, копия репозитория будет создана быстро и не займет много дополнительного места на диске.
Теперь можно сделать ряд изменений в экспериментальной ветке:
Начинаем мой великий эксперимент над рецептом гуакамоле:
В экспериментальный репозиторий можно коммитить без опасений:
Вы можете смело вносить изменения, фиксируя результат когда захотите. Это дает вам всю мощь контроля версий даже для вашего безумного эксперимента, причем никто не пострадает.
Если вы решите, что эксперимент не удался, то можете просто удалить весь каталог с экспериментальным репозиторием. Нет репозитория — нет проблемы.
Но если все получилось, то вам нужно лишь протолкнуть ваши новые правки:
И куда же они протолкнулись?
Строчка, начинающаяся с «default», содержит путь к репозиторию, в который
Не забывайте, что проталкивание изменений в этот репозиторий...
… не приводит к тому, что изменения появляются в рабочем каталоге.
Видите? Правки про «Queso» в пятом наборе изменений. Но в моем основном репозитории работа остановилась на четвертом наборе изменений. От того, что кто-то протолкнул изменения в репозиторий, рабочий каталог не обновился, и пятый набор изменений в нем не появился. Так что я по-прежнему работаю с четвертым набором изменений.
Если я захочу узнать, что в пятом наборе изменений, то мне нужно будет использовать команду
Видите, что произошло? Изменения были получены, но они были после той версии, с которой я работал. Команды
Сейчас репозитории выглядят так:
Mercurial гибок в вопросах пересылки изменений из репозитория в репозиторий. Можно протолкнуть изменения прямо из экспериментального в центральный репозиторий:
Так пятый набор изменений был отправлен из экспериментального прямиком в центральный репозиторий. Теперь, если я вернусь в свой основной репозиторий, то увижу, что в нем больше нечего проталкивать!
Это потому, что Mercurial знает, что в центральном репозитории этот (пятый) набор изменений уже откуда-то есть. Это по-настоящему полезно, потому как иначе Mercurial мог бы попытаться применить изменения заново и серьезно запутаться.
Дизайнер Джим, после того как ему предложили работу, пообещал приступить к делам сразу же. Однако он не появлялся на работе еще два месяца. Почти все уже забыли и о нем, и о том, что предлагали ему работу, так что когда он весь такой загорелый впервые появился в офисе, честно сказать, никто толком не мог понять, кто он и что вообще происходит. Это было достаточно забавно. Внешность у него типическая. В конце концов, во всем разобрались, но так как он был новеньким, все постеснялись спросить у него, что, черт побери, произошло. И про шрамы и синяки на лице тоже не спросили. Неважно. Просто мы ненавидим этого парня.
Иногда случается, что спустя месяцы, вы обнаруживаете, что сделали ошибку.
Картофельные чипсы? Чё за..?!
Mercurial может изъять старый набор изменений из истории. Mercurial смотрит на набор изменений, определяет обратные действия и изменяет текущий рабочий каталог. Давайте попробуем изъять ту старую ревизию номер 2.
Матерь божья, что это было?
Вообще говоря, времени могло пройти много. Чипсы вообще могли исчезнуть из рецепта. Много всего жуткого могло произойти. А значит, иногда после изъятия ревизии объединить изменения невозможно. В таких случаях вы получите конфликты слияния (merge conflicts), которые вам нужно как-то разрешить. Вот об этом и поговорим в следующей части.
Вот то, что вы должны уметь делать после прочтения данной части:
Продолжение здесь:
Hg Init: Часть 5. Процесс слияния
Одно из главных преимуществ Mercurial состоит в том, что вы можете использовать личные клоны репозитория для экспериментов и разработки новых возможностей. Если что-то пошло не так, можно все исправить за мгновение.
Часть 4. Исправляем ошибки
Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное:
Emacs, как же я тебя люблю. Как бы то ни было, все можно исправить. Наиболее распространённым способом справиться с такими проблемами является использование команды
hg revert
:hg revert
возвращает файлы к состоянию, зафиксированному в репозитории.
Эта команда вернет файлы в именно то состояние, что было у них в момент последнего коммита. Mercurial не любит что-либо удалять, так что вместо того чтобы затереть рецепт на свинском латинском, он переименовал файл:
А что если все зашло слишком далеко и вы уже закоммитили?
Есть команда
hg rollback
, которая спасет вашу шкуру, но только если вы еще не протолкнули (push) ошибочный коммит в другой репозиторий. Эта команда отменяет один коммит.hg rollback
отменяет один коммит, при условии, что вы не протолкнули его в другой репозиторий.
Представьте, что вы хотите поставить большой эксперимент в свободное время. Ваш босс нанял нового дизайнера, Джима. С тех пор дизайны, которые вы получаете, стали просто абсурдны. В них кислотный зеленый текст, ничего не выровнено (на это есть «художественные» причины, ага) и юзабилити хромает. Вы хотите прийти на работу в выходной и все переделать, но боитесь коммитить свои изменения, так как не уверены на 100%, что ваши идеи лучше, чем у этого рехнувшегося дизайнера. Джим курит траву практически все время с момента пробуждения до момента отхода ко сну. Вы не хотите использовать это против него, да и все думают, что эта привычка никого не касается до тех пор, пока дизайны в порядке. Но всему есть предел. Так ведь? И дизайны у Джима не в порядке, и вообще он дерзкий какой-то.
При работе с Mercurial вы можете просто создать клон всего репозитория:
Это не настолько расточительно, как может показаться. Так как в репозиториях recipes и recipes-experiment хранится одно и то же (пока), то Mercurial воспользуется "жёсткими ссылками" (hard links). А значит, копия репозитория будет создана быстро и не займет много дополнительного места на диске.
Теперь можно сделать ряд изменений в экспериментальной ветке:
Начинаем мой великий эксперимент над рецептом гуакамоле:
В экспериментальный репозиторий можно коммитить без опасений:
Вы можете смело вносить изменения, фиксируя результат когда захотите. Это дает вам всю мощь контроля версий даже для вашего безумного эксперимента, причем никто не пострадает.
Если вы решите, что эксперимент не удался, то можете просто удалить весь каталог с экспериментальным репозиторием. Нет репозитория — нет проблемы.
Но если все получилось, то вам нужно лишь протолкнуть ваши новые правки:
И куда же они протолкнулись?
hg paths
отображает список известных удаленных (remote) репозиториев.
Строчка, начинающаяся с «default», содержит путь к репозиторию, в который
hg push
проталкивает изменения если вы явно не укажете другой репозиторий. Обычно в этой строчке указан путь к репозиторию, с которого вы делали клон. В данном случае это локальный каталог, но в качестве пути может быть и URL. Не забывайте, что проталкивание изменений в этот репозиторий...
… не приводит к тому, что изменения появляются в рабочем каталоге.
hg parent
отображает набор изменений, находящийся в рабочем каталоге.
Видите? Правки про «Queso» в пятом наборе изменений. Но в моем основном репозитории работа остановилась на четвертом наборе изменений. От того, что кто-то протолкнул изменения в репозиторий, рабочий каталог не обновился, и пятый набор изменений в нем не появился. Так что я по-прежнему работаю с четвертым набором изменений.
Если я захочу узнать, что в пятом наборе изменений, то мне нужно будет использовать команду
hg update
:Видите, что произошло? Изменения были получены, но они были после той версии, с которой я работал. Команды
push
и pull
просто пересылают изменения между репозиториями. Эти команды не влияют на то, с чем я работаю в данный момент.Сейчас репозитории выглядят так:
Mercurial гибок в вопросах пересылки изменений из репозитория в репозиторий. Можно протолкнуть изменения прямо из экспериментального в центральный репозиторий:
Так пятый набор изменений был отправлен из экспериментального прямиком в центральный репозиторий. Теперь, если я вернусь в свой основной репозиторий, то увижу, что в нем больше нечего проталкивать!
Это потому, что Mercurial знает, что в центральном репозитории этот (пятый) набор изменений уже откуда-то есть. Это по-настоящему полезно, потому как иначе Mercurial мог бы попытаться применить изменения заново и серьезно запутаться.
Дизайнер Джим, после того как ему предложили работу, пообещал приступить к делам сразу же. Однако он не появлялся на работе еще два месяца. Почти все уже забыли и о нем, и о том, что предлагали ему работу, так что когда он весь такой загорелый впервые появился в офисе, честно сказать, никто толком не мог понять, кто он и что вообще происходит. Это было достаточно забавно. Внешность у него типическая. В конце концов, во всем разобрались, но так как он был новеньким, все постеснялись спросить у него, что, черт побери, произошло. И про шрамы и синяки на лице тоже не спросили. Неважно. Просто мы ненавидим этого парня.
Иногда случается, что спустя месяцы, вы обнаруживаете, что сделали ошибку.
Картофельные чипсы? Чё за..?!
Mercurial может изъять старый набор изменений из истории. Mercurial смотрит на набор изменений, определяет обратные действия и изменяет текущий рабочий каталог. Давайте попробуем изъять ту старую ревизию номер 2.
Матерь божья, что это было?
Вообще говоря, времени могло пройти много. Чипсы вообще могли исчезнуть из рецепта. Много всего жуткого могло произойти. А значит, иногда после изъятия ревизии объединить изменения невозможно. В таких случаях вы получите конфликты слияния (merge conflicts), которые вам нужно как-то разрешить. Вот об этом и поговорим в следующей части.
Проверь себя
Вот то, что вы должны уметь делать после прочтения данной части:
- Откатить случайные изменения. До того, как они зафиксированы в репозитории, и после.
- Локально склонировать репозиторий для экспериментов.
- Проталкивать изменения в разные репозитории.
- Откатить старую ошибку, которая давным-давно была зафиксирована в репозитории.
Продолжение здесь:
Hg Init: Часть 5. Процесс слияния