Альтернативные процедуры при использовании Mercurial Hg

Question

Я бы хотел узнать ваше мнение о том, какие из следующих процедур мне следует использовать, или какие из них более предпочтительны при использовании Mercurial.Предположим, что у меня последний код.
Первая процедура следующая:

1. Выполняю свою работу
2. hg commit
3. При необходимости повторите шаги 1 и 2
4. Когда я буду готов нажать I hg pull, hg update
5. hg merge, hg commit
6. hg push

Второе:

1. Выполняю мою работу
2. , когда я готов совершить I hg pull, hg update
3. hg commit, hg push

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

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

Answer 1

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

• с первым рабочим процессом, вы выполните слияние на шаге 5.

• со вторым рабочим процессом, вы делаете то же самое слияние как часть обновления на шаге 2.

Первый рабочий процесс кажется более безопасным для многих, поскольку вы работаете над уже совершенной работой. Это означает, что возвращаться в чистое состояние тривиально, если объединение оказывается сложным: hg update -C ..

Но вы можете вернуть исходные файлы даже со вторым рабочим процессом: hg resolve --all --tool internal:local вернет объединение, которое началось hg update, и выберет оригинальную версию для всех файлов.

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

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

Итак, если у вас есть эта история после пулла:

... [a] --- [b] --- [x] --- [y] --- [z]
               \
                [d] --- [e]

, где вы создали x до z, тогда обычное слияние создаст эту историю:

... [a] --- [b] --- [x] --- [y] --- [z]
               \                       \
                [d] --- [e] ----------- [f]

с ребазом вы получаете

... [a] --- [b] --- [d] --- [e] --- [x'] --- [y'] --- [z']

где x' до z' - это перебазированные версии от x до z (разные идентификаторы изменений, потому что у них разные предки).

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

Answer 2

По сути, вы уже ответили на вопрос самостоятельно:

Первая процедура - это процедура по умолчанию для DVCS, поскольку она использует преимущества типичных функций DVCS
(локальный репозиторий, более быстрые коммиты, потому что нет сетиболее подробная история из-за множества мелких коммитов против нескольких крупных ...)

Использование второй процедуры не является «неправильным» или «плохим», но вы должны осознавать тот факт, чтовы используете DVCS, как если бы он был CVCS, поэтому вы намеренно решили не использовать некоторые преимущества DVCS (см. выше).

Люди, которые являются давними пользователями CVCS (например, ваши коллеги, вероятно), часто предпочитают вторую процедуру, потому что это чувствует больше, чем они уже знают.
Плюс, объединение работает лучше в DVCS, чем CVCS, поэтому ихАргумент "возможные проблемы со слиянием", вероятно, только потому, что в прошлом у них были проблемы в CVCS , и он предполагал, что в DVCS будет то же самое (что не так).