Рабочий процесс Mercurial, позволяющий работать над несколькими отдельными задачами параллельно

Question

Здесь проводятся многочисленные дискуссии, посвященные вопросам, которые, похоже, связаны с этим вопросом, но на самом деле ничего не дало прямого ответа на него.По сути, используя Mercurial, я хочу иметь возможность работать над несколькими независимыми задачами в рамках одного и того же проекта одновременно.

Например, мне одновременно поручено работать с ошибками X & Y. Я работаю надX на некоторое время, пока я не достигну точки, где мне нужно отложить ее на несколько дней.Скажем, мне нужен вклад от кого-то еще, кто находится вне офиса.Итак, я хочу перейти к работе над ошибкой-Y.Ясно, что один из вариантов - просто создать новый клон стабильного репозитория.Проблема в том, что требуется новый рабочий каталог, новый проект Eclipse, yada-yada ... Я хотел бы иметь возможность сохранить одну рабочую копию.

С помощью SVN я мог бы создать новую ветвь в хранилищедля каждой задачи и просто переключать мою рабочую копию между ними.С ClearCase я мог создать новую деятельность для каждого.В обоих случаях я мог работать над каждой задачей независимо, в чистой среде.Затем, когда я закончу с заданием, я смогу зафиксировать / отправить только это в центральный репозиторий.

Я прочитал о Hg по имени ветви и закладки.Я уверен, что где-то там есть решение для нашего рабочего процесса, но я пока не вижу его.Может кто-нибудь объяснить, какие шаги я могу использовать для достижения этой цели?Можно ли создать две головы в моем локальном репозитории, между которыми я могу просто переключаться?А затем обновить / зафиксировать / нажать / потянуть эти головы самостоятельно?На практике я мог бы даже не объединить их локально, просто подтолкнуть каждого к нашему стабильному репо, когда он будет готов.Я просто думаю об этом совершенно неправильно?Я очень новичок в Hg (и DVCS в целом) и пытаюсь разработать рабочий процесс для него.

Answer 1

Процесс, который вы описываете, действительно прост в реализации с Mercurial, и есть много способов сделать это.

Например, вы можете использовать анонимные ветки:

1. Поместите тег или закладку на набор изменений, который вы хотите использовать в качестве начала для обеих разработок.
2. Разработайте ваше первое исправление, сделав столько коммитов, сколько вам нужно
3. Если вы хотите начать другую линию разработки, просто обновите ранее сохраненный набор изменений
4. Разработайте второе исправление и передайте изменения

Вы только что создали две анонимные ветви в своей рабочей копии, начиная с определенного набора изменений.

Вы абсолютно не ограничены количеством анонимных веток или их отправной точкой, вы даже можете создавать новые анонимные ветки в своих анонимных ветках.

В некоторых случаях такие инструменты, как TortoiseHG или расширение GraphLog , действительно могут помочь вам понять, кто является родителями каждой ветви и каков наилучший способ их объединения.

Закладки - это всего лишь способ легко отслеживать различные изменения, вы можете ставить закладки на каждую из ваших новых головок. В зависимости от используемой версии Mercurial, закладка будет «следовать» за каждым новым коммитом, который вы делаете в своей конкретной ветке или нет.

Вы также можете использовать именованную ветвь для достижения той же цели, но проблема в том, что вы не можете легко удалить именованную ветвь после того, как она была создана, имя все равно останется их.

PS: этот рабочий процесс или что-то очень похожее описано в следующем сообщении в блоге: http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/

Answer 2

При работе с несколькими задачами / ошибками я предпочитаю использовать закладки над именованными ветками.Они не загромождают вашу историю информацией о ветвлении (но это может быть личным предпочтением).

Обычно вы просто работаете над веткой по умолчанию.Чтобы отслеживать эту «основную линию разработки», мы создаем закладку с именем «master» (или как бы вы ее не называли).Теперь, прежде чем приступить к работе с ошибкой X, создайте закладку «bugX».

• hg мастер закладок
  • ... по умолчанию работайте на ветке по умолчанию ...
• hg закладка bugX
  • ... работа над bugX
• hg commit -m "bugX 1"
  • ... работа над bugX
• hg commit -m "bugX 2"

Затем вы должны работать над ошибкой Y, потому что вы должны, например, ждатьдля ввода кого-то еще.Для этого сначала вернитесь к главной закладке (где вы оставили «основную строку»), создайте новую закладку для ошибки Y и начните работать над ней.

• hg update master
• hg закладка bugY
  • ... работа над bugY
• hg commit -m "bugY 1"

Youтакже теперь нужно прекратить работу над ошибкой Y, и вы хотите продолжить работу на «главной линии».Сначала вы берете самые последние изменения из центрального репо, а затем начинаете работать над основной веткой.Когда функция закончена, вы можете нажать ее.Обязательно нажимайте только на главную ветку с помощью «hg push -r master»:

• hg update master
• hg pull --rebase
  • ... workна мастере
• hg commit -m "новая функция 1"
  • ... работа на master
• hg commit -m "новая функция 2"
• рт.ст. push -r master

Иногда вы можете закончить ошибку X:

• hb update bugX
  • ... работать над ошибкой X
• hg commit -m "bugX fixed"

Это исправление теперь должно быть перенесено в ветку master иподтолкнул к центральному репо.Вы можете объединить его с «hg merge bugX» или, что еще лучше, перебазировать его.Когда все будет сделано, удалите закладку bugX:

• hg update bugX
• hg rebase -b bugX -d master
• hg bookmark -f master
• hg закладка -d bugX
• hg push -r master

"hg bookmark -f master" необходим для того, чтобы основная закладка теперь указывала на последний набор изменений bugXкоторый был перебазирован поверх главной ветки (я думаю, что это делается автоматически с помощью Mercurial 2.1).

Теперь эту же процедуру можно выполнить с bugY, и вы получите прямую историю.

В команде вы могли бы даже рассмотреть возможность перемещения главной закладки в центральное хранилище, чтобы ее не поддерживали после извлечения (hg push -B master).

Этот рабочий процесс также описан более подробно илименьше в этом блоге .

Answer 3

Я написал руководство о использовании именованных веток для задач , которые могут оказаться полезными.Вы пишете в своем ответе:

Вот несколько ошибок, которые я нашел:

• Слияние вашей ветви функций с «по умолчанию», когда вы готовы нажать - вы можете »t просто перенесите свою ветку в удаленный репозиторий

Вам нужно hg push --new-branch, если вы хотите, чтобы Mercurial создал новую именованную ветку в удаленном репозитории.Это связано с тем, что ветви являются глобальными и долгоживущими - поэтому вы не должны просто создавать их с временными именами.

• Когда вы нажимаете, убедитесь, что вы выбрали только толкать ветку «по умолчанию» -если вы этого не сделаете, он также попытается выдвинуть любые другие ветви функций, которые еще не были переданы

Вы можете использовать hg push --branch X, чтобы только выдвинуть ветку X (и любых предков, конечно).

• Hg будет жаловаться, что ваш push создает новые удаленные ветви - это нормально, если ветвь уже локально объединена

На самом деле, локальное слияние не имеет ничего общего с этим сообщением - оно приходит каждый раз, когда вы вводите новую ветку, и не важно, слито оно или нет.Именованные ветви - это действительно инструмент, который вы используете, когда хотите иметь несколько головок в общем хранилище.Называя ветви, вы избегаете путаницы, когда люди тянут и обновляют: hg update default все равно даст вам основную линию разработки, даже если может быть ветка X с очень экспериментальным и нестабильным кодом.

Answer 4

Обычно я просто создаю именованные ветви для любого подпроекта или нетривиального исправления ошибки. Вы можете легко переключаться между ветками с помощью hg update. Когда я закончу с чем-то, я просто вернусь к стандартному.

Вот статья с хорошей информацией о ветвлении в Mercurial: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 5

Хорошо, так что я думаю, что понял это.Я думаю, что я буду использовать именованные ветви.Спасибо всем за помощь.

Вот несколько уловок, которые я нашел:

1. Слияние вашей ветви функций с настройкой по умолчанию, когда вы готовы нажать - вы не можете просто нажать своюпереход к удаленному репозиторию
2. Когда вы нажимаете, убедитесь, что вы выбрали только переход по ветке «по умолчанию» - если вы этого не сделаете, она также попытается выдвинуть любые другие ветви функций, которые еще не были переданы
3. Hg будет жаловаться, что ваш толчок создает новые удаленные ветви - это нормально, если ветвь уже объединена локально

Если у кого-то, смотрящего на это, есть дополнительные комментарии и / или предложения, я 'буду рад их услышать.Я не на 100% доволен этим решением.