Как правильно мержить в main из dev, если там есть незаконченные фичи?
Допустим, у нас есть ветки main, dev
изначально они все одинаковые
A(main)
B(dev)
затем от ветки dev делаем ветку задачи С, выполняем ее, и мержим в дев
A
B-B1
пока задача проверяется нам еще дают задачу
согласно инструкциям которые я виде мы опять делаем ветку от dev D, выполняем задачу и мержим в dev
A
B-B1-B2
теперь нам говорят что B2 ок, и можно отправлять в прод, B1 при этом еще на контроле/заморожен
но, ветку D мы делали от коммита B1, и она содержит в себе изменения из B1
и если написать
git switch A
git merge D
то получим в A и B1, которого там не должно быть (или я такой кривой, а на самом деле это не должно быть так?
никак не пойму как же правильно делать мердж отдельных мелких задач, когда предыдущие еще не согласованы
вижу пока 2 варианта
1. cherry-pick
2. ветки для задач делать от main а не от dev.
но в обоих случах разница между main и dev может быть огромная. и не факт что заработает, т.к. в dev могут быть еще не апрувнутые багфиксы которые как раз и нужны для работы b2 но я об этом не в курсе, т.к. это делают другие.
вариант с ожиданием согласования всех задач и обновлением мейна раз в "период" не подходит.
P.S, под контролем имеется ввиду "клиент сказал что хочет сам увидеть все на тестовом прежде чем на прод отправить"
а смотреть и думать он может месяцами..
Сергей delphinpro, а как узнать какие не подтвержденные, если доступ у меня только к моим задачам.
я ж хз что там было одобрено. B1 не факт что моя задача была, а может быть чьей то еще..
согласно инструкциям которые я виде мы опять делаем ветку от dev D, выполняем задачу и мержим в dev
Ну вообще неправильно так делать. Нужно либо от main делать ветку. Либо делать от main ветку dev-release-555 и уже от нее делать все ветки, потом эти ветки вливать в dev, потом вливать в dev-release-555 и её вливать в main с релизом.
Фича ветки делаем только от актуального main.
Для проверки мержим фича-ветку в dev, но не удаляем.
Когда одна или несколько фичей проверены и готовы, то делаем от main релизную ветку и мержим туда все готовые фичи, прогоняем тесты и если всё ок, то мержим релизную вету в main.
Ну и полезно мержить main в фича ветки, когда main обновился.
Решение более правильное - не делать так. Мержить надо когда все работает, а если есть неработающий функционал, то:
- Либо комментировать функциональность которая еще не работает
- Либо сделать эту функциональность доступной через фича-флаги. Эти флаги соответственно никто не должен выставлять
- Либо мержить только работающие ветки, а та, в которой не работает/не закончена - в нее мержить уже готовую мастер ветку
Мержить через cherry-pick - такое себе: одна ошибка и ты ошибся (фатально)
пока фича не доделана - не мержить.
мержом в мейн нужно смержеть мейн в свою фича ветку, убедиться что нет конфликтов ни по синтаксису ни по логике. Если фича долго в разработке можно в принципе периодически мержить в нее мейн, чтобы не сильно отставать и уменьшить работу на потом.
А уже потом мержить в мейн, в идеале еще и со squash
Есть еще варианты более сложные, если фичу разделяют на разные спринты, на разные команды - тогда внедряешь заглушки или конфиг/апи для включения/выключения фичи
если читать пост, то я там явно пишу что
клиент пишет - хочу хотелку
разраб эту хотелку реализует
но клиент пишет, что прежде чем в прод отправить хочу хотелку увидеть на тестовом сайте
потом он может месяц думать нравится она ему или нет, или вносить правки.
и так по каждой хотелке.
идеальный вариант из книг по работе с гитом не рассматривается за отсуствием в 99% компаний
Деплойте на тестовом сайте фича-ветку?
Не знаю какой у вас проект, но если сайт занимает немного, может несложно организовать много тестовых сайтов под разные фичи
