Если у меня есть куча незафиксированных изменений и я хочу отложить их, вместо этого работая над чем-то другим, а затем (например, через несколько дней) вернуться к ним и продолжить работу. Какой рабочий процесс для этого был бы самым простым? (Пока у меня есть только опыт работы с базовыми функциями Mercurial). Моим обычным методом было создание новой ветки с помощью клона, но могли быть способы получше.
Ответы:
У вас есть несколько вариантов:
Положите предметы на полку. Это сохраняет изменения и удаляет их из рабочего каталога, чтобы ветвление могло продолжаться. Это не создает набор изменений.
hg shelve --all --name "UnfinishedChanges"
hg unshelve --name "UnfinishedChanges"
Обновление / редактирование : в более новых версиях Mercurial может потребоваться использование
hg shelve -n "UnfinishedChanges"
hg unshelve "UnfinishedChanges"
Вы все еще можете использовать его --nameв качестве альтернативы -n, но, похоже, ртуть больше не нравится --name. Кроме того, --allбольше не требуется, и Mercurial действительно будет волноваться по этому поводу.
Заплатите очередь элементов, используя 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это слишком сложно для такой обычной ситуацииЯ думаю, что лучший способ - просто зафиксировать свои изменения, чем вернуться к набору изменений, прежде чем начинать эти изменения и работать оттуда. Есть несколько мелких проблем, позвольте мне проиллюстрировать:
Допустим, у вас есть набор изменений A. Затем вы начинаете свои изменения. На этом этапе вы хотите отложить это на время. Прежде всего, завершите свою работу:
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) изменения не должны покидать ваш компьютер до фиксации / время нажатия.