Пример использования
Второй возможный рабочий процесс, так же очень простой: Вы разработчик-одиночка и хотите использовать Mercurial, чтобы отслеживать изменения, внесенные вами.
Чтобы начать новый проект, вам нужно инициализировать репозиторий, добавить файлы и делать коммиты (фиксации, commits) Каждый раз, когда вы заканчиваете какую-либо часть вашей работы
Так же, время от времени, вам нужно будет просматривать историю, чтобы посмотреть, на сколько вы продвинулись.
Процесс
Основы из хранения логов
Инициализация репозитория, добавление файлов, наблюдение за изменениями и их фиксация:
$ hg init project $ cd project $ (Добавление файлов) $ hg add # Говорим Mercurial следить за всеми файлами $ (Внесение некоторых изменений) $ hg diff # Просмотр изменений $ hg commit # Сохранение изменений $ hg cp # Копирование файлов или папок $ hg mv # перенос файлов или папок $ hg log # просмотр истории
Просмотр предыдущих ревизий
В отличие от хранения истории, вам, возможно, понадобится вернуться назад (к предыдущим версиям) и внести там какие-либо изменения, например потому что в ранних изменениях была допущена ошибка и вам необходимо исправить её там, где она появилась
Для того, чтобы посмотреть предыдущую версию Вашего кода, вы можете использовать команду update. Предположим, Вы хотите посмотреть третью ревизию:
$ hg update 3
После этого ваш код должен вернуться в 3-ю ревизию, 4-й коммит (Mercurial начинает отсчет с 0). Чтобы проверить, что вы на самом деле находитесь в нужной ревизии, воспользуйтесь командой identify -n.
$ hg identify -n
Примечание: Команда identify без параметров возвратит короткую форму уникального идентификатора ревизии. Этот идентификатор используется для внутреннего представления в Mercurial. Если вы говорите кому-нибудь о версии, до которой вы обновились, нужно использовать именно этот идентификатор, т.к. порядковые номера могут отличаться у разных людей. Если хотите узнать о причинах этого, прочитайте Основы Mercurial. Если вы находитесь в самой последней ревизии, hg identify -n вернет "-1"
Для обновления до самой последней ревизии вы можете использовать в качестве имени ревизии "tip"
$ hg update tip
Примечание: Если в каком-либо месте какая-нибудь команда жалуется на что-нибудь, то вам лучше прочитать, что она вам сообщает и следовать её совету
Примечание: Так же, вместо hg update вы можете использовать короткий вариант этой команды: hg up. Таким же образом вы можете сократить hg commit до hg ci
Примечание: Чтобы получить ревизию, лишенную файлов, просто обновитесь в ноль (null) с помощью hg update null. Это "нулевая" ревизия до добавления в репозиторий каких-либо файлов.
Исправление ошибок в ранних версиях
Когда вы находите баг в ранних ревизиях, у вас на выбор есть два варианта: либо вы можете исправить его в текущем коде, либо вернуться назад в истории и исправить баг там, где он впервые появился, что сделает историю более чистой
Итак, чтобы воспользоваться "правильным" путем, во-первых, нужно обновиться до старой ревизии, исправить баг и закоммитить исправления. Затем вам нужно объединить эти ревизии и закоммитить объединение. Не беспокойтесь - слияние в Mercurial быстрое и безболезненное, вы в этом убедитесь позже
К примеру, пускай баг появился в 3-й ревизии:
$ hg update 3 $ (исправление бага) $ hg commit
Теперь исправления уже отображены в истории. Нам нужно только объединить их с текущей версией кода:
hg merge
Если при объединении возникли конфликты, используйте hg resolve - так же и merge посоветует вам сделать тоже самое, если случится конфликт
Для начала, выведем список файлов с конфликтами:
$ hg resolve --list
Затем, разрешите конфликты по одному. resolve попытается провести объединение еще раз
$ hg resolve <имя_конфликтующего_файла> (Исправьте конфликт в ручную, если будет необходимо)
Пометьте исправленные фалы как разрешенные
$ hg resolve --mark <имя_конфликтующего_файла>
Закоммитьте объединение, как только разрешите все конфликты. Этот шаг необходимо проделать и в том случае, когда конфликтов не было!
$ hg commit
В этот момент ваши исправления объединены со всей остальной вашей работой, вы може продолжить работу над проектом. Дополнительно, история показывает, где вы исправили баг, таким образом вы всегда можете посмотреть, где именно находилась ошибка
Примечание: Большинство объединений просто работают (без геморроя). Вам надо лишь применить resolve, если при объединении возникают жалобы.
Итак, теперь вы можете создавать репозиторий, сохранять изменения, откатываться к предыдущим ревизиям и вести разработку с нелинейной истрией при помощи коммитов в ранние ревизии и слияния изменений с текущим кодом.
Примечание: Если вы пофиксили баг в предыдущей ревизии, а одна из следующих ревизий переместилаа или копировала этот файл, то этот фикс распространится и на целевой(ые) файл(ы) при объекдинении. Это основной довод в пользу того, что вы должны использовать hg cp и hg mv
Комментариев нет:
Отправить комментарий