Должен ли я создавать новую ветку для каждой новой обнаруженной ошибки?

Question

Мы используем JIRA в качестве нашей системы тикетов. Новые ошибки / тикеты отправляются в эту систему. После исправления ошибки мы создаем новую сборку и тестируем ее на нашем сервере разработки. Если все хорошо, мы отправляем его на живой сервер. Теперь я обычно работаю над стволом без каких-либо ответвлений, чтобы исправить ошибки. Это конечно проблема. Потому что в нашей системе может быть много ошибок, но только определенные исправляются за один раз. Однако, если я закреплю их все в стволе, а не в ветке, то мы будем вынуждены проверить их все, даже если у нас не было достаточно времени, чтобы проверить их все. Как вы обычно исправляете ошибки и ветки и т.д ..? (Я не уверен, объяснил ли я это очень хорошо).

Answer 1

Вот стратегия, которую я использую. Я развиваюсь в основном стволе. Когда программное обеспечение выпущено, я разветвляю его (скажем, v1.0). Когда появятся ошибки, исправьте ствол ветви, а затем объединитесь с основным стволом. Вот хороший обзор доступных стратегий: http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html

Answer 2

Я не уверен, что это нормальная стратегия, но мы все работаем над транком, а затем возвращаем исправления ошибок в ветки релиза. Наш основной транк всегда «нестабилен», и когда мы чувствуем, что у нас есть транк в освобожденном состоянии, мы разветвляем его в ветку релиза. С этого момента buyfixes переносятся обратно в ветку релиза, а новые функциональные возможности добавляются только в транк. Это означает, что вы можете запустить ветку релиза через тестирование и сосредоточиться на тестировании исправлений.

Answer 3

У нас та же проблема (или почти), и я думаю, что каждая команда разработчиков имеет ее. К сожалению, я пока не могу дать вам ответ по опыту, но только теоретический.

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

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

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

Answer 4

Один из распространенных режимов работы состоит в том, что развернутое программное обеспечение находится в отдельной ветви, которая получает только исправления. Где вы на самом деле разрабатываете эти исправления, в основном не имеет значения; во избежание вмешательства в текущую разработку имеет смысл разработать исправление поверх «живой» ветки, затем протестировать / зафиксировать / развернуть в работающей системе и затем объединить исправление обратно в транк.

Answer 5

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

Если ваши инструменты и язык поддерживают это, переход на каждую ошибку, которую вы решили исправить (и функцию, которую вы решили реализовать), не является плохой идеей. Он позволяет вам разрабатывать и тестировать каждое исправление / функцию, когда у вас есть для этого бюджет и расписание, и объединять их обратно в транк, когда вы будете готовы.

Answer 6

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

С другой стороны, если вы используете Subversion, ветки стоят дороже (с точки зрения создания и переключения / обновления), а объединение сложнее. Часто соотношение затрат и выгод в новой ветке недостаточно велико (особенно для мелких ошибок), чтобы сделать его полезным.

Answer 7

Если вы не используете распределенный SCM (Mercurial, Git, ...), где ветвление в основном бесплатное, ветвление для каждой ошибки звучит как неоправданное количество работы.

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

Мы используем Mercurial, и ветвление для исправления ошибок и последующего объединения изменений вполне выполнимо в распределенном SCM

Answer 8

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

Кроме того, каждая версия продукта имеет разработчика и основную ветвь. Разработчики могут свободно присоединяться к ветке dev, не опасаясь вмешательства в Release (только другие разработчики!)