Сразу предупреждаю, тут рассматривается самый-самый примитивный способ работы с системой контроля версий.
- не используем ветки
- не используем bitbucket
- один дев-сайт и продакшен.
Мне надо было работать над проектами, в которых есть интеграция с 1С. Так бы я вносил изменения на продакшене. Но, когда работаешь с выгрузками, необходимо иметь свою копию базы данных.
Система контроля версий позволила забирать изменения с продакшена на дев, и выкладывать изменения с дева на продакшен. Некоторые проекты так работают у меня в течение многих лет.
В командной работе мы теперь чаще используем git. Но Mercurial — довольно надежная вещь, и её тоже можно применять.
Если вы под root, не забываем авторизоваться под пользователем системы. Из под root будет предупреждениеИнициализация репозитория на продакшене:cd /home/bitrix/www/
hg init
|
Файлы, которые игнорируем в .hgignore:
touch .hgignore
mcedit .hgignore |
Примерное содержание:
syntax: regexp
^robots.txt$
^\.htaccess$
^log.*\.txt$
^sitemap.*\.xml$
^bitrix/.*
^upload/.*
^desktop_app/.*
^NB/.* |
Настройки пользователя:touch .hg/hgrc
mcedit .hg/hgrc |
Примерное содержание:
[ui]
username = Main Artemy <mail@askaron.ru> |
Первый коммит в репозиторий:hg add
hg commit -m "First commit"
|
Создание второго репозитория: дев. КлонированиеПапка /home/bitrix/ext_www/dev.site.ru/ должна существовать и быть пустой.
hg clone /home/bitrix/www/ /home/bitrix/ext_www/dev.site.ru/ |
Настраиваем второго пользователя - назовем его Dev Artemy, чтобы отличатьcd /home/bitrix/ext_www/dev.site.ru/
mcedit .hg/hgrc |
примерное содержание
[paths]
default = /home/bitrix/www
[ui]
username = Dev Artemy <mail@askaron.ru>
|
Результат. У нас есть две копии сайта на одном сервере. У каждого сайта есть свой локальный репозиторий. Репозиторий ДЕВ знает, где лежит продакшен.
Пропущенные файлы и папки можно скопировать или создать символические ссылки для bitrix и upload.
Работа с изменениями:Допустим, мы что-то сделали на деве. Надо перенести данные на продакшен. Мы сначала заберем изменения с продакшена, а потом отправим изменения с дева.
Мы предполагаем случай, когда кто-то может вносить изменения на продакшене.
Не забываем авторизоваться под пользователем системы. Из под root будет предупреждение.
1. Идем в рабочий каталог Продакшена, фиксируем измененияcd /home/bitrix/www
hg status
hg addremove
hg commit -m "Забрать изменения с продакшена"
hg status |
2. Идем в рабочий каталог Деваcd /home/bitrix/ext_www/dev.site.ru/
hg status
hg addremove
hg commit -m "Dev repository update"
hg status |
3. Получение изменений на Деве с продакшенаcd /home/bitrix/ext_www/dev.site.ru/
hg incoming
hg pull |
Может оказаться, что изменений нет и все хорошо.
Но если изменения на продакшене кто-то делал.
Если hg pull пишет
#pulling from /home/bitrix/www
#searching for changes
#adding changesets
#adding manifests
#adding file changes
#added 1 changesets with 6 changes to 6 files
#(run 'hg update' to get a working copy) |
,то можно сделать update.
hg update -v
hg status
hg commit -m "update dev from main repository" |
- на продакшене что-то изменилось, но можно обновить. Шаг 4 пропускаем.
Если
#pulling from /home/bitrix/www
#searching for changes
#1 changesets found
#adding changesets
#adding manifests
#adding file changes
#added 1 changesets with 1 changes to 1 files (+1 heads)
#(run 'hg heads' to see heads, 'hg merge' to merge)
|
, то надо мёрджить hg merge (4 шаг)
4. Слияние ( hg merge ). Если после hg pull все плохоМожет выдать ошибку про конфликт с каким-нибудь файлом и имя этого файла. Создаст файл .orig рядом.
Сам файл может быть изуродован стрелочками внутри, где что-то изменилось >>>>>>> other, <<<<<<< local
Для примера проблемный файл в корне проекта style.css изменился и там и там
#merging style.css
#warning: conflicts during merge.
#merging style.css failed!
#0 files updated, 0 files merged, 0 files removed, 1 files unresolved
#use 'hg resolve' to retry unresolved file merges or 'hg update -C' to abandon |
Редактируем файл style.css в IDE, исправляем, что не так, удаляем рядом файл .orig иначе он попадет в проект
Помечаем что этот файл корректно слит
После pull, merge и resolve надо зафиксировать изменения
hg status
hg commit -m "merge from main repository" |
5. Отправляем из репозитория дева в репозиторий продакшена:Может быть все хорошо
#pushing to /home/bitrix/www
#searching for changes
#adding changesets
#adding manifests
#adding file changes
#added 1 changesets with 3 changes to 3 files |
Или (маловероятно) может быть ошибка - значит в центральном репозитории что-то опять изменилось, и кто-то опять там сделал коммит! Надо скачать изменения еще раз.
#pushing to /home/bitrix/www
#searching for changes
#abort: push creates new remote heads!
#(did you forget to merge? use push -f to force)
#abort: push creates new remote heads! |
6. Перед записью изменений идем на продакшен смотрим репозиторий. Достаточно 3 последних коммитаЭтот шаг необязательный. Но полезно, чтобы остановиться немного и подумать перед hg update -v.
cd /home/bitrix/www
hg log -l 3 |
#changeset: 4:2d53dfe77407
#tag: tip
#parent: 3:462ea219bfbc
#parent: 1:629e8d1ec342
#user: Dev Artemy <mail@askaron.ru>
#date: Fri Jun 20 17:23:19 2014 +0400
#summary: merge from main repository
#changeset: 3:462ea219bfbc
#user: Dev Artemy <mail@askaron.ru>
#date: Fri Jun 20 16:07:13 2014 +0400
#summary: Removing files
#changeset: 2:a38e1ef018ad
#parent: 0:625a2cd91ced
#user: Dev Artemy <mail@askaron.ru>
#date: Fri Jun 20 16:00:22 2014 +0400
#summary: Catalog big update |
7. Перекрестились и записываем изменения на продакшенcd /home/bitrix/www
hg update -v |
Отличия от git.Прикольная команда
hg addremove - фиксирует перед коммитом изменения. Фиксирует новые и удаленные файлы.
.hgignore позволяет использовать регулярные выражения.
hg pull не изменяет файлы. В меркуриал после нее следуют
hg update или
hg merge.
Если
hg merge заканчивается ошибкой слияния, то файл надо отредактировать в IDE и сделать что-то вроде
hg resolve -m style.css