Каков стандартный процесс фиксации для Hg?

Question

Это

1. тянуть
2. обновление
3. 1008 * слияние *
4. 1010 * совершить *
5. 1012 * толчок *

? Или вы можете сделать коммит первым?

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

Answer 1

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

Если вы сделаетепри обновлении тяги (hg pull; hg update или короче hg -u pull) и при наличии любых невыполненных не зафиксированных изменений любые изменения, поступающие извне, будут объединены с вашими изменениями.Когда возникают конфликты, может быть трудно решить, как должен выглядеть результат слияния, потому что вы не можете легко отличить ваши изменения от изменений, которые были объединены.

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

1. hg commit
2. hg pull -u (если объединение не требуется, перейдите к 5)
3. hg merge
4. hg commit
5. hg push

Обновление: Как отметил Мартин Гайслер, можно получить «оригинал» измененнымверсия файла, использующая:

hg resolve --unmark the-file
hg resolve --tool internal:local the-file

или для всех файлов одновременно:

hg resolve --unmark --all
hg resolve --tool internal:local -all

Тем не менее, я считаю системный коммит первым.В конце концов, это личное предпочтение ...

Answer 2

1. Редактировать
2. Commit
3. Перейти к 1, пока не выполнится
4. Прицепные
5. Объединить и зафиксировать
6. Нажмите, если хотите.

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

Фиксация рано, коммит часто.

Если вы этого не сделаете, вы упускаете огромное преимущество DVCS.

Answer 3

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

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

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

Answer 4

но, вероятно, вам нужно выполнить слияние, прежде чем вы сможете выполнить толчок, потому что у вас не может быть конфликтов в центральном репо

Неправильное утверждение и плохое понимание распределенного рабочего процесса ипараллельное развитие.

1. Вы можете объединить головы перед нажатием, но не имеют или должны .Push может помещать любые данные в репо, если это необходимо и должно быть таковым.

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

(Примечание: " рекомендуется для извлечения и объединения до")

Вы можете использовать commit-pull-merge, stash-pull-unstash-merge, выполнять выборку с модифицированным WC и объединяться на лету, вообще не сливать головы или спорадически и push --force с +1 головой - не существует общего правила для всех .И любой такой рабочий процесс не создает «конфликтов в центральном репо», а только различных DAG .

каждой точки расхождения, которая появляется в случае существующего вашего и другие changeset от commmon parent в вашем (или даже центральном) репо - это точка запуска анонимных веток в Hg, что (технически) является абсолютно законным, применимым и обычным способом.То, как они обрабатываются, определяется политикой и соглашением между разработчиками, PM, QA-командой и другими

Лично я предпочитаю завершить свою задачу (за один или несколько коммитов), после того, как она потянет и возможно слияние , когда оно утверждено политикой развития