commit-pull-merge-push или pull-merge-commit-push?

Question

Мы начали использовать Mercurial несколько недель назад.Большинство разработчиков придерживаются этого рабочего процесса:

• работает над функцией
• commit -m "Работает над функцией ABC"
• pull -u
• Есливетвь
  • слияние
  • коммит -m "Слияние"
  • push

Сегодня один из наших разработчиков предложилмы делаем:

• работаем над функцией
• потяните -u
• если ветвь
  • объедините
• commit -m "Работал над функцией ABC"
• push

Таким образом, у нас намного меньше изменений "Объединить" в журнале.

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

Answer 1

Мне больше нравится ваша оригинальная процедура, но разумные люди могут, конечно, не согласиться. Я считаю, что нужно объединить реальную часть работы по разработке программного обеспечения и сделать так, чтобы она была первоклассным гражданином в нашем процессе.

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

Для людей, которые просто не переносят ветвистую историю, обычный предпочтительный рабочий процесс:

• работа над функцией
• 1010 * совершить *
• pull --rebase
• толчок

, где опция --rebase появляется при извлечении после включения расширения rebase . Я не фанат rebase, потому что это технически переписывающая история, которая противоположна тому, как должен работать mercurial, но я в этом быстро растущем меньшинстве.

Итог, если вы действительно не хотите, чтобы ветвистая история использовала rebase - не обновляйте незафиксированные изменения, поскольку их трудно отменить.

Answer 2

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

Это может быть особенно удобно, если вы столкнулись с конфликтом при слиянии с Feature A и хотите спросить об этом разработчика, который работал над Feature A, но у него обеденный перерыв. С вашим первым рабочим процессом вы можете прервать слияние и просто продолжать, пока этот разработчик не вернется и вы не будете готовы к слиянию снова. Со вторым рабочим процессом, вы просто застряли и должны найти что-то еще (или сделать еще один клон хранилища и работать в нем, пока не сможете объединиться, но мне это кажется хуже).

Answer 3

Это не сработает:

• работа с функцией
• pull -u
• если ветвь
  • слияние
• commit -m "Работает с функцией ABC"
• push

Если у вас есть локальные изменения, вы не можете объединяться.То, что вы / можете / делаете, это:

• работа над функцией
• pull -u
• работа над функцией
• pull -u
• работа с функцией
• pull -u
• ...
• commit -m "Работа с функцией ABC"
• push

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