GIT-ветвление и попытка не запутаться

[prokuratdm]

немного намудрили, но по сути вы используете устоявшийся практики, которые я опишу чуть нижу:
1) merge strategy — классическая стратегия для многих проектов
2) rebase strategy — у вас под 5 пуктом идет
используете стратегии которые прописаны прямо в документации
3) feature-branch — известный всем подход, только вы немного добавляете в него наименования… я бы посоветовал ветки называть в соответсвии с именованием тасков в жире или другой системе.
4) использование tag для минорных и мажорных версий — тоже стандартный подход.

новое что предлагаете?

[PavelZ11]

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

[gecube]

Спасибо, интересная публикация. Чужой опыт, которые тиражируется — это всегда здорово.
Единственное, что я не увидел важный момент — предположим, выясняется, что в версии 1.1.1 есть некий баг, который зарепортил кастомер. И, соответственно, он есть в ветках до (1.0 и старее), в текущей (1.1) и в следующих (1.2, 1.3… вплоть до мастера). Как будете чинить? Как потом будете накладывать патчи? Начиная с мастера и вниз? Или начиная с версии 1.1.1 (которая уже будет 1.1.2) и вверх (вплоть до мастера), и вниз (в 1.0, в 0.9 и т.д.)
На хабре была статья про это из какого-то доклада, но я благополучно ссылку пролюбил ((( А вопрос, между прочим, для "коробочной" разработки очень важный.

[PavelZ11]

Спасибо! Мы обычно исправляем баг в той версии, где он обнаружен, а дальше переносим его во все ветки, которые сейчас активны. При этом все версии (в активных ветках) сместятся на единицу вперед (например, 1.0.2, 1.1.2, 1.2.3). Под активной веткой имеется ввиду ветка с версией, на которой есть сданный заказчику продукт.

[ALexhha]

а дальше переносим его во все ветки, которые сейчас активны.

cherry pick или что то более продвинутое?

[PavelZ11]

Обычно cherry-pick

[tbb]

В общем случае, если баг нетривиальный, не факт что предыдущие/последущие версии ему подвержены. И не факт, что в разных версиях получится полечить его идентичными изменениями, особенно если версии ушли далеко друг от друга. Более того, проверенное на одной версии решение может сломать что-то на другой версии продукта.

Кажется часть проблем может решить функциональный тест, который можно запустить на необхдимых сборках до и после фикса. А как вы решаете подобные проблемы, если они, конечно, есть?

[PavelZ11]

Тестировщики проверяют наличие бага во всех актуальных версиях. Там где воспроизведется там и исправляем. Как правило, мы обновляем «ответвившиеся» версии по отдельности и соответственно тестируем исправления по отдельности (если место исправления не покрыто автотестами). При этом исправления вносятся не механически, а с оценкой последствия изменений. Ну и после внесения изменений прогоняются автотесты по всему функционалу платформы (но если честно, ими покрыт далеко не весь функционал и это проблема)

[Lemyyyr]

А что вы делаете, если, например, коммит С2 не должен быть установлен в релиз v1.0? А вот коммит С3 должен попасть в этот релиз? Если создавать релизную ветку от С3, то неизбежно будет захвачен и С2. А если создавать релизную ветку из С1, то как потом туда переносить корректно изменения только из нужных коммитов, при этом не затрагивая ненужные предыдущие?
Это самая распространённая ситуация. Когда делается с десяток задач, но в поставку входит только часть из них. Остальные задачи либо ещё не протестированы, либо баги не исправлены, а может этот функционал вообще пока не нужен или блокируется другой задачей.

[PavelZ11]

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