Новий блог (1) hg shevle, або що робити якщо почав кодувати не в тій гілці

hg shevle, або що робити якщо почав кодувати не в тій гілці

Оскільки історично ми з товариші використовуємоMercurialу роботі, то часто (принаймні в мене) виникає ситуація, коли починаєш кодувати над тій гілці, тобто. локальна копія не в, скажімо, розробці, а в виробництві. Причому часто з'ясовується це вже після того, як великий шматок коду написаний. Що робити в цьому випадку? Є звичайно варіанти геморойні, на кшталт ручного копіювання змін з однієї гілки в іншу будь-яким способом.

Або, припустимо, треба терміново перейти на іншу гілку і там щось пофіксувати, замовник уже порвав скайп, а в робочій копії робота половини дня, причому в такому непотрібному стані, що й закомітити не хочеться, і пушити не можна, але переходити на іншу гілку просто необхідно тут і зараз.

Розробники Mercurial якраз для подібних ситуацій вигадали командуhg shelve. Так як я не фанат консолі, то показуватиму як користуватися цією фічею з графічної обв'язки TortoiseHg.

Отже, намагаємося перейти на іншу гілку, і бачимо лайку на наявність незафіксованих змін. Там є кнопка для виклику Shelve tool. Натискаємо її і бачимо щось подібне:

новий

Ліворуч у нас поточні зміни, а праворуч у нас т.зв. Шелф. Полиця, стелаж - дуже зручний переклад у цьому випадку. По суті, це patch файл, в який можна перенести зміни з робочої копії. Так само їх можна звідти повернути знову ж таки в робочу копію. Кнопки зі стрілками у верхній частині дозволяють перенести один/всі файли на полицю/з полиці. Полку можна очистити. Полку можна створити нову. Загалом, перенесли все, що потрібно в праву частину, і закрили.

Допитливий читач виявить після цих дій пару цегли підсвоїм стільцем і поставить питання "Яка #$%, де вся моя робота за півдня. ". Але нічого страшного, вся робота в цілості та безпеці, на полиці. Обновляємось на потрібну нам гілку і через меню Repository-Shelve. Викликаємо знову цю ж тулзу. Вибираємо використаний раніше shelf. Переносимо зміни з правої частини в ліву, закриваємо і вуа-ля, всі зміни на своєму місці можна продовжувати конкурувати з індусами.

На даному етапі можуть виникнути проблеми, якщо гілки дуже сильно відрізняються, щось на зразок merge conflict. Я з такими випадками поки не стикався, спеціально перевіряти як з них виходити було ліньки. За ідеєю можна переносити окремими змінами (chunk-ами), а все, що конфліктує потім вже додавати вручну, для чого навіть відповідні кнопки передбачені.