Лучшие практики для контроля версий и исправления ошибок

Question

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

В настоящее время мы используем Subversion для управления исходным кодом в небольшой (3 разработчика) команде, которая в основном разрабатывает в Visual Studio 2008. Мы ожидаем, что команда может объединить до 8 разработчиков в течение следующего года, и любая поддержка предыдущих выпусков станет более сложный В то время как большинство клиентов находятся в текущей версии, некоторые отстают.

Answer 1

Управление исходным кодом может справиться с этим довольно легко, и было разработано для этого.

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

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

Не забудьте указать номер ошибки в комментарии, так как это облегчит отслеживание изменений.

Answer 2

Как насчет: ветвь для основной версии с исправлениями ошибок, применяемыми к ветвям (ветвям) по мере необходимости, а также применяемыми (или объединенными) обратно в транк.

Answer 3

Где я работаю, у нас есть несколько проектов, работающих одновременно. Чтобы избежать этой проблемы, у нас есть несколько вариантов исходного кода. Например, первый выпуск Variant 1.0. Мы создаем ветку из этого выпуска, скажем, Variant 2.0, для всей будущей разработки. Если нам нужно исправить ошибку, мы делаем это в основном варианте, который в настоящее время равен 1.0 и может выпустить его. Когда Variant 2.0 готов к запуску, мы объединяем его с тем, что находится в главной ветви (в данном случае 1.1), и это становится новой основной магистралью. В какой-то момент у нас одновременно работало 4 филиала.

Слияние кода может занимать много времени, и вы должны быть осторожны, чтобы не вносить новые ошибки во время слияния, но если у вас есть подходящий инструмент сравнения кода, то это не должно быть слишком плохо. Некоторое время назад мы произвели слияние, используя Beyond Compare, в исходном каталоге с 10 000 файлов, и это заняло одно утро.