Подвижный Рабочий процесс для малочисленной команды
Я работаю в команде 3 разработчиков, и мы недавно переключились от CVS до Подвижного. Мы используем Подвижный при наличии локальных репозиториев на каждой из наших рабочих станций и получения по запросу/продвижения к серверу разработки. Я не уверен, что это - лучший рабочий процесс, поскольку легко забыть Продвигать после Фиксации и 3 способов, которыми конфликты слияния могут вызвать реальную головную боль. Есть ли лучший рабочий процесс, который мы могли использовать, поскольку я думаю, что сложность распределенного VC перевешивает преимущества в данный момент.
Спасибо
4 ответа
Если вы часто сталкиваетесь с трехсторонним слиянием, это может быть связано с тем, что вы и члены вашей команды слишком много работаете в одном направлении. Mercurial довольно хорошо справляется со слияниями сам, пока вы все не редактируете одни и те же строки файла. Если возможно, вы могли бы разделить работу более четко и избежать некоторых головных болей, связанных с большими слияниями. Также обратите внимание, что это все еще будет проблемой для CVS, поскольку он, возможно, хуже справляется с объединением, чем mercurial.
Вам также не нужно проталкиваться после каждого коммита. Ваш рабочий процесс может выглядеть примерно так:
- Коммит части некоторой функции.
- Коммит еще части какой-то функции.
- Коммит последней части функции.
- Фиксируем исправления глупых ошибок.
- Выкладываем полную версию фичи в репо.
В какой-то степени это похоже на Going Dark, но это можно смягчить, если убедиться, что функции в приведенном выше примере имеют небольшой объем.
Мы используем Mercurial, имея локальные репозитории на каждой из наших рабочих станций и загружая / отправляя на сервер разработки.
Для меня это звучит нормально. Моя команда примерно вдвое больше, и она отлично работает.
Я не уверен, что это лучший рабочий процесс, так как легко забыть Push после фиксации,
Вам не нужно нажимать после каждой фиксации; вы толкаете, когда хотите толкнуть. В этом главная идея DVCS: Commit и Push отличаются!
и конфликты трехстороннего слияния могут вызвать настоящую головную боль.
Вы много работаете над одними и теми же строчками кода? В моей команде из 5-6 программистов, которые нажимают / вытягивают несколько раз в день и совершают до пары десятков раз в день, я не могу вспомнить, когда мне в последний раз приходилось вручную разрешать конфликты слияния. Конечно, не в последний месяц или два.
Есть ли лучший рабочий процесс, который мы могли бы использовать, поскольку я думаю, что сложность распределенного VC перевешивает преимущества на данный момент.
Возможно, вам следует описать свой рабочий процесс более подробно, потому что единственная сложность по сравнению с централизованным контролем версий, с которой я сталкиваюсь в типичный рабочий день, - это, возможно, одна команда, а преимущества огромны. Выполнение «hg blame» только один раз сэкономит мне больше времени по сравнению с централизованной версией, чем все «hg push», которые мне приходилось печатать весь год!
Похоже, вы все вносите изменения в одну и ту же ветку. У этого есть неудовлетворительный побочный эффект, заключающийся в том, что вы объединяете изменения друг друга почти при каждой отдельной фиксации, что было бы хорошо, за исключением того, что ручное вмешательство в конфликты - это не то, что вы хотите делать каждый раз, когда нажимаете .
Вот рабочий процесс, который я бы предложил. Идея состоит в том, чтобы более активно использовать ветвление, поэтому вам нужно реже выполнять слияние с основной веткой.
Попросите каждого разработчика разрабатывать каждую функцию в отдельной ветке.Таким образом:
вы избегаете постоянного слияния изменений, внесенных другими людьми, и
вы свободны от давления, заставляющего продвигать незавершенную работу до следующего человека, «затрудняет слияние».
Когда функция «есть». done ", и если кажется, что изменения применяются без ошибок (суждение), объедините функциональную ветвь непосредственно с главной ветвью и удалите функциональную ветвь.
Если функция сильно отстает от основной ветви (многие функции объединены) или если в противном случае слияние кажется затруднительным:
объедините мастер в ветку функций.
Находите и исправляйте любые ошибки в полной изоляции от других разработчиков.
Предполагая, что функция готова к работе, слейте ее с мастером (обратите внимание: теперь слияние в этом направлении будет чистым по определению). Если нет, можно просто продолжить развитие.
Забудьте все, что вы знаете о CVS. Mercurial не похож на него, даже если некоторые команды кажутся чем-то похожими.
Прочтите http://hginit.com/ . Следуйте примерам.
Забудьте все, что вы знаете о CVS.
Я серьезно. Это самая сложная часть. Научитесь доверять своему инструменту.