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

Question

[Василий Мажекин]

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

Какие плюсы и минусы каждого способа? Поделитесь опытом, какой способ вы используете для своей разработки?

Comments

[Виталий Хоменко]

GitFlow

Answer 1

[Евгений Вольф]

Поделитесь опытом, какой способ вы используете для своей разработки?

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

Лучшая формула работы, из моего личного опыта - это "думать головой", а не слепо следовать какому-то набору правил.

Answer 2

[dmitriy]

второй вариант, при первом работа ведется с хотфиксами

Answer 3

[Vitsliputsli]

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

Comments

[Василий Мажекин]

А от чего ветвится надо для новых фич/доработок, если они связаны очень часто, типа одна от другой зависит?

[Vitsliputsli]

Я бы такую фичу создавал бы на основе другой фичи, это усложняет общую картину, но других вариантов нет, имхо. Лучше, конечно, избегать такого на этапе планирования. Со схемой как у вас я работал, но у нас были rolling-releases (с такими требованиями по-другому никак) и это работало даже при слабом тестировании из-за слабого зацепления кода, поймать регрессию было редкостью. Соответственно, если фича зависела от другой фичи, то первую в любом случае ждали в продакшн, поэтому реализация первой, в прод, затем второй, либо ветвиться как написал выше.

[Василий Мажекин]

тогда лучше может ветвиться от девелопа и туда же сливать готовые ветки, как рекомендуется в git flow, вроде так путаницы меньше...
потом в конце спринта, вывалить все в stage, стабилизировать, и в релиз?

[Vitsliputsli]

Василий Мажекин, так и нужно делать, если бы вам не приходилось выбирать фичи перед самым релизом.