Блог - Розробка - Mercurial комміти,злиття
Коли людина працює з репозиторієм одна – проблем, як правило, не виникає. Незрозумілі починаються, коли з репозиторієм працюють 2 або більше осіб. Додає бардаку "візуальний" софт - TortoiseHg, наприклад. Люди звикли тикати одну кнопку і щоб "все було добре". А тут купа кнопочок, ще й із невиразним перекладом (якщо використовується україніфікована версія).
Найголовніша концепція, яку необхідно зрозуміти: HG – це децентралізована система контролю версій. У будь-який момент часу є, як мінімум, два повноцінні репозиторії: на віддаленому сервері і локальний, у папці проекту. Усі зміни, насамперед, відбуваються у локальному репозиторії. Щоб оновити репозиторій на сервері, необхідні додаткові кроки.
Отже, робочий процес. Прийшли вранці на роботу, починаємо працювати і виконуємо в консолі з директорії проекту (маю на увазі, що проект вже є і ввечері попереднього дня нормально поклали все на сервер):
hg pull -u
Командою hg pull ми оновлюємо з сервера наш локальний репозиторій (тільки репозиторій! файли проекту не торкаються). За оновлення файлів проекту відповідає прапорець -u. Це все робиться на випадок, якщо були якісь зміни коду.
hg commit -m "Виправив помилку #58"
Цією командою ми зафіксували зміни коду у локальному репозиторії. Іншим розробником ваші зміни поки що недоступні! Вони зберігаються лише у вас.
До кінця робочого дня ми маємо локальний репозиторій з кількома коммітами в нем. Тепер нам треба відправити все наше добро на віддалений сервер - щоб наші правки були доступні іншим розробникам. Виконуємо команду:
hg push
Цією командою ми надсилаємо всезміни з локального репозиторію у віддалений. Якщо у віддаленому репозиторії зранку не було жодних змін – то все відбувається нормально.
Але ми розглянемо випадок із конфліктом. Тому у відповідь ми отримуємо:
pushing to .searching для changesabort: push creates нові remote heads on branch 'default'!( ви повинні кинути і merge or use push -f to force)
Не треба лякатися такого повідомлення - це лише означає, що у віддаленому репозиторії відбулися зміни і нам необхідно оновити свій локальний репозиторій і злиття своїх змін з іншими змінами. Для цього виконуємо:
hg pull
Цією командою оновлюємо локальний репозиторій із віддаленого. Отримуємо повідомлення:
догляд за змінами
зміни зміни
збереженняfile changesadded 2 changesets with 1 changes to 1 files (+1 heads))
Тепер у нас у локальному репозиторії цікава ситуація – у нас вийшло 2 гілки. Одна гілка - зміни з сервера, друга гілка - наші зміни. Але нам необхідно з цих двох гілок зробити одну, в якій були б всі зміни. Для цього виконуємо команду:
hg merge
І якщо злиття відбулося без конфліктів - у нас виходить код проекту, до якого застосовано всі зміни. Ми маємо зафіксувати ці зміни:
hg commit -m "Злиття"
І проштовхнути їх на сервер:
hg push
Якщо ж при злитті були конфлікти, то відкривається програма злиття з трьома версіями конфліктного файлу. Це вікно всіх початківців шокує :) Якщо вікно не відривається, то, можливо, у вас ненастроєно або не встановлено утиліту злиття. Рекомендую встановити та налаштувати – інтернеті безліч статей з цієї теми.
Утиліт злиття багато, не буду зупинятися на якійсь конкретно, розповім загальні принципи. Всі вони відрізняються трохи зовнішнім виглядом, управлінням, деякі відрізняються кривістю (вбудована мержилка в NetBeans 6.9.1 виводить мене з себе своєю незручністю, тому використовую meld ).
Отже, відображаються 3 версії файлу: local, base, remote (у деяких є ще й 4 версія - merged). Саме BASE/MERGED вводить усіх у ступор.
Розшифрую, що до чого:LOCAL - файл з вашими правкамиREMOTE - файл із сервераBASE - вихідний файл, " не правлений", до якого була спроба застосування змін (локальних та з сервера).
Тут ми наближаємося до дуже делікатного моменту. Як я говорив вище – у нас є дві гілки. В даному випадку гілки анонімні - тобто вони не мають назви і виникли вони через конфлікт. Після злиття розгалуження зникне і гілки зіллються в один "ствол". Тому всі зміни вносимо до файлу LOCAL - тобто до нашого поточного проекту.
Як саме вирішити конфлікт - тут уже розробник сам прикладає голову, як модифікувати код, щоб були й ті та інші зміни у підсумковому файлі.
Дивимося та виправляємо всі конфлікти, зберігаємось і виходимо з програми.
Після всіх виправлень дивимося на працездатність коду (актуально, якщо зміни були нетривіальні). Після чого комітімо наше злиття і проштовхуємо на сервер командами:
hg commit -m "Злиття"hg push
Робочий день закінчено, із чистою совістю йдемо додому. Всім дякую!
PS: Обговорити, поставити питання щодо HG можна у спеціальній темі на нашому форумі.