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

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 файлов, и это заняло одно утро.