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

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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Если у вас есть локальные изменения, вы можете не сливаться. Что вы/можете/делаете так:

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

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