Стратегия ветвления для серьезного редизайна - PullRequest
0 голосов
/ 19 мая 2011

Мне интересно, какова лучшая стратегия ветвления для этого сценария.Моя компания планирует переписать свое веб-приложение, которое изменит около 50% кода и может занять несколько месяцев.В то время как эта разработка происходит, нам также нужно будет внести небольшие улучшения в текущую версию приложения.

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

1 Ответ

3 голосов
/ 19 мая 2011

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

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

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

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

...