mazhekin
@mazhekin
Frontend, Backend Web Developer

От какой ветки нужно ветвить фиче-бранчи для разработки?

Помогите с выбором. Над проектом работают несколько разработчиков. Есть две обычных ветки. Master и develop. От какой ветки нужно ветвить бранч для разработки фичи?
1) от мастера, и потом вливать готовую фичу в девелоп, потому что каждая фича должна быть готова в любой момент по желанию заказчика влита в мастер и в релиз.
2) от девелопа и потом готовую фичу опять же в девелоп влить. И потом в конце спринта все
влить в мастер.

Какие плюсы и минусы каждого способа? Поделитесь опытом, какой способ вы используете для своей разработки?
  • Вопрос задан
  • 252 просмотра
Решения вопроса 1
Пригласить эксперта
Ответы на вопрос 3
Wolfnsex
@Wolfnsex
Если не хочешь быть первым - не вставай в очередь!
Поделитесь опытом, какой способ вы используете для своей разработки?
Лично мы используем такой способ:
1. Есть мастер ветка, туда попадает только полностью оттестированный код (обратите внимание - не в конце какого-то спринта; не после того, как на горе рак свистнет; а после прохождения всех этапов тестирования)
2. Есть dev-ветка, ею заведует старший разработчик и по мере необходимости "подливает" туда фиче-ветки.
3. Есть много фич-веток, в которых работают отдельно взятые личности, при этом откуда они будут брать кодовую базу для доработки - их личная трагедия. Если при слиянии возникают конфликты - есть старший разработчик, если ему что-то непонятно - есть авторы кода, которых можно позвать и спросить "какого тут происходит?".

Лучшая формула работы, из моего личного опыта - это "думать головой", а не слепо следовать какому-то набору правил.
Ответ написан
@dmitriylanets
второй вариант, при первом работа ведется с хотфиксами
Ответ написан
@Vitsliputsli
Есть разные варианты даже в git-flow. В вашем случае, с учётом того, что вы делаете фичи, а затем выбираете, что пойдет в релиз (не очень понятно как вы формируете спринт при этом), ветка develop вам по-сути не нужна. Ветка develop предназначена для интеграции разных фич и проверки их совместной работы, в вашем случае это откладывается до финального тестирования релиза. Такой путь даёт гибкости, но может увеличить время финального тестирования, оправдан для несложных проектов и/или проектов с действительно слабым зацеплением, но даже в этом случае требуется постоянный контроль со стороны тимлида.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы