Якщо у мене є маса незапущених змін і я хочу відкласти це під час роботи над чимось іншим, а потім пізніше (через кілька днів) поверніться до нього і продовжуйте роботу. Який був би найпростіший робочий процес для цього? (Поки що у мене є лише досвід роботи з основним функціоналом Mercurial). Моїм звичним методом було створення нової гілки за допомогою клону, але можуть бути і кращі способи.
Відповіді:
У вас є кілька варіантів:
Покладіть предмети. Це зберігає зміни та видаляє їх з робочого каталогу, щоб відділення могло продовжуватись. Це не створює набір змін.
hg shelve --all --name "UnfinishedChanges"
hg unshelve --name "UnfinishedChanges"
Оновлення / редагування : можливо, знадобиться використовувати новіші версії
hg shelve -n "UnfinishedChanges"
hg unshelve "UnfinishedChanges"
Ви все ще можете використовувати --nameяк альтернативу -n, але меркурій, схоже, вже не любить --name. Крім того, --allце більше не потрібно, і меркурій насправді вигадує над ним.
Виправити чергу за допомогою елементів mq. Це не надто відрізняється від прилавків у деяких відношеннях, але поводиться інакше. Кінцевий результат той самий, зміни видаляються і їх можна додатково повторно застосувати пізніше. При натисканні патчі є логічними наборами змін, при вискакуванні вони зберігаються в іншому місці і не є частиною історії встановлених змін.
hg qnew "UnfinishedWork"
hg qrefresh
hg qpop
hg qpush "UnfinishedWork"
Введіть їх на місцевому рівні, оновіть попередній набір змін і продовжуйте роботу та використовуйте анонімні гілки (або кілька заголовків). Якщо ви хочете зміни, ви можете об'єднати голови. Якщо ви не хочете змін, можна зняти набір змін.
hg commit -m"Commiting unfinished work in-line."
hg update -r<previous revision>
hg strip -r<revision of temporary commit>
Прив’язати їх до названої гілки. Потім робочий процес стає таким же, як і варіант 3 - злиття або смуга, коли ви будете готові.
hg branch "NewBranch"
hg commit -m"Commiting unfinished work to temporary named branch."
hg update <previous branch name>
Особисто я використовую варіант 3 або 4, оскільки я не заперечую зняття наборів змін або реєстрацію часткового коду (до тих пір, поки з часом не натиснуть). Це можна використовувати разом із новими новинками Phase, щоб приховати локальні набори змін від інших користувачів, якщо виникне потреба.
Я також використовую rebaseкоманду для переміщення наборів змін, щоб уникнути злиття, де злиття нічого не додасть до історії коду. Злиття я, як правило, зберігаю для активності між важливими гілками (наприклад, гілками випуску) або діями з довгоживучої гілки функцій. Існує також histeditкоманда, яку я використовую для стиснення наборів змін, де "базікання" з них зменшує значення.
Черги з виправленнями також є загальним механізмом цього, але вони мають семантику стека. Ви натискаєте і виправляєте патчі, але патч, який знаходиться "під" іншим патчем у стеці, вимагає також натиснення і на один поверх нього.
Попередження , як і у всіх цих опцій, якщо файли мають більше змін після тимчасових змін, які ви зберігали / в черзі / розгалужували, під час розпакування / натискання / об'єднання буде потрібне дозвіл злиття.
--allне розпізнається. це поведінка за замовчуванням, щоб все-таки відкласти всі зміни.
Особисто мені не подобається жодна відповідь, розміщена до цих пір:
shelveдля швидких виправлень (просто для переміщення моїх невмілих змін до іншої гілки, якщо я зрозумію, що я неправильна). Ви говорите про дні, ні в якому разі я б не відкладав щось на дні.mqце занадто складно для такої звичайної ситуаціїЯ думаю, що найкращий спосіб - це просто здійснити свої зміни, ніж повернутися до набору змін, перш ніж розпочати ці зміни та працювати звідти. Є деякі незначні проблеми, дозвольте мені проілюструвати:
Скажімо, у вас є набір змін А. Чим ви починаєте свої зміни. У цей момент ви хочете відкласти його на деякий час. Перш за все, виконайте свою роботу:
hg ci -m "Working on new stuff"
Якщо хочете, ви можете додати закладку, щоб полегшити повернення пізніше. Я завжди створюю закладки для своїх анонімних гілок.
hg bookmark new-stuff
Поверніться до набору змін перед цими модифікаціями
hg update A
Звідси ви працюєте та генеруєте набір змін C. Тепер у вас є 2 головки (B і C), вас попередить, коли ви намагаєтесь натиснути. Ви можете натиснути лише на одну гілку, вказавши голову цієї гілки:
hg push -r C
Або ви можете змінити фазу new-stuffгілки на секретну. Таємні набори змін не будуть висунуті.
hg phase -r new-stuff --secret --force
mqце трохи занадто складним для всього цієї ситуації, але вона має досить широкий спектр застосування, в тому числі цей, що це варто витратити час , щоб стати вільно з ним.
Щоб зберегти локальні незмінні зміни, найпростіший спосіб для мене - це просто зберегти їх як патч-файл.
hg diff > /tmp/`hg id -i`.patch
і коли вам потрібно повернутися до попереднього стану:
hg up <REV_WHERE_SAVED>
hg patch --no-commit /tmp/<REV_WHERE_SAVED>.patch
/tmpі , hg id -iі він буде працювати на Windoze теж.
hg upне потрібна там.
Ви можете просто клонувати своє репо кілька разів. У мене, як правило, корінь клону, а потім декілька дітей звідти. Приклад:
Усі 4 дитини клонуються з кореня і штовхають / тягнуть до / з кореня. Потім корінь штовхає / витягує з головного репо в мережі / Інтернеті десь. Корінь виступає у ролі вашої особистої області постановки.
Тож у вашому випадку ви б просто клонували нове репо і почали працювати. Залиште свою «поличену» роботу в спокої в іншому репо. Це так просто.
Єдиним недоліком є використання дискового простору, але якщо це викликає занепокоєння, ви взагалі не будете користуватися DVCS;) О, і це все-таки забруднює список "останніх проектів" Visual Studio, але що таке.
[Редагувати наступні коментарі]: -
На закінчення ... те, що ви робите, є цілком нормальним і нормальним. Я б зауважив, що це найкращий спосіб працювати, коли це правда: 1) це недовговічність 2) вам не потрібно співпрацювати з іншими розробниками 3) змінам не потрібно залишати ваш ПК, поки не буде здійснено / час натискання.