Mercurial Workflow для небольшой команды

Question

Я работаю в команде из 3 разработчиков, и мы недавно перешли с CVS на Mercurial. Мы используем Mercurial, имея локальные репозитории на каждой из наших рабочих станций и вытягивая / отправляя на сервер разработки. Я не уверен, что это лучший рабочий процесс, так как его легко забыть нажать Push после фиксации, а 3-сторонние конфликты слияния могут вызвать настоящую головную боль. Есть ли лучший рабочий процесс, который мы могли бы использовать, так как я думаю, что сложность распределенного VC перевешивает преимущества на данный момент.

Спасибо

Answer 1

Если вы сталкиваетесь с множеством трехсторонних слияний, это может быть из-за того, что у вас слишком много совпадений в том, над чем вы и члены вашей команды работаете.Mercurial довольно хорош в обработке слияний, если вы все не редактируете одни и те же строки файла.Если возможно, вы могли бы разделить работу более четко и избежать некоторых головных болей крупных слияний.Также обратите внимание, что это по-прежнему будет проблемой с CVS, так как это, возможно, хуже при слиянии, чем mercurial.

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

• Фиксация части какой-либо функции.
• Фиксация еще некоторых функций.
• Фиксация последней части функции.
• Фикс исправления ошибок для глупых ошибок.
• Нажмите полную функцию для репо.

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

Answer 2

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

2. Чтение http://hginit.com/. Следуйте примерам.

3. Забудьте все, что вы знаете о CVS.

4. Я имею в виду. Это самая сложная часть. Научитесь доверять своему инструменту.

Answer 3

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

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

1. Пусть каждый разработчик разработает каждую функцию в отдельной ветке. Таким образом:

   • вы избегаете постоянного слияния изменений от других людей, а

   • вы свободны от давления, чтобы подтолкнуть незавершенную работу до того, как следующий парень "затруднит слияние".

2. Когда функция «выполнена» и если кажется, что изменения применяются корректно (экспертный вызов), объедините ветвь функции напрямую с основной веткой и удалите ветвь функции.

3. Если объект отстает от основной ветви (многие объекты объединены) или если объединение в противном случае кажется трудным:

   1. объединение мастера в ветвь функций.

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

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

Answer 4

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

Это звучит хорошо для меня. Моя команда примерно вдвое больше, и она прекрасно работает.

Я не уверен, что это лучший рабочий процесс, так как легко забыть нажать Push после коммита,

Вам не нужно нажимать после каждого коммита; Вы нажимаете, когда хотите нажать. Это большая идея о DVCS: что Commit и Push различны!

и 3 способа конфликта слияния могут вызвать настоящую головную боль.

Вы много работаете над одними и теми же строками кода? В моей команде из 5-6 программистов, которые нажимают / вытягивают несколько раз в день и совершают до пары десятков раз в день, я не могу вспомнить, когда в последний раз мне приходилось вручную разрешать конфликты слияния. Конечно, не в прошлом месяце или двух.

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

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

Answer 5

Несмотря на это, мы - команда такого же размера, работающая с Mercurial в первый раз, и мы начали с той же проблемы.

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

Надеюсь, вы все разберетесь!