AS
а зачем для этого гит то? это же типичная тема для clearCase
Size: a a a
2021 October 07
3
а clearCase могет в интеграцию с джирой?
AS
понятия не имею, а если нет в чем проблема написать скрипт из полсотни строк на питоне который смогет сгенерить вьюху?
3
а зачем есть есть гит и джира и они из коробки интегрируются
3
если только оч нужно именно с clearCase связать
AS
затем что мержить фичабренчи в релизную ветку в систему которая не могет работвть с файлами автономненько - такое себе
AS
То что Альберт описал - прям 100% кейс как используется CC
фича разрабатывается, на измененые файлыы вешаются фича-теги
затем интегратор собирает вьюху перечисляя фича теги и строит релиз
фича разрабатывается, на измененые файлыы вешаются фича-теги
затем интегратор собирает вьюху перечисляя фича теги и строит релиз
PD
Ну, мне вот стремно, что мердж делается из кучи бранчей автоматически )
И получается, что для этого нужны и фичабранчи и фичатогглы, а это уже как-то грустно, можно было бы только вторым обойтись )
И получается, что для этого нужны и фичабранчи и фичатогглы, а это уже как-то грустно, можно было бы только вторым обойтись )
АС
а что стремного-то?
принципиально если?
принципиально если?
АС
оно отлажено и работает
АС
зато кодер знает только свою ветку, коммит и пуш
АС
дальше вообще не его забота
PD
Тем, что нужно писать код с расчетом на то, что его автосмерджат.
Ну вот у меня две фичи, в каждой надо поменять, например, генерацию описания операции.
При мердже будет или конфликт (в лучшем случае) или один вариант затрет другой (в среднем) или будет полная чушня (в третьем).
И разработчик должен понимать, а что произойдет.
Миграции БД в этом случае становятся нетривиальными, подход Flyway уже не сработает, нужно выстраивать список зависимостей миграций и в рантайме опеределять их последовательность (это реально, но из стандартных средств никто так не умеет).
И так далее - много разных тонкостей и особенностей.
Ну вот у меня две фичи, в каждой надо поменять, например, генерацию описания операции.
При мердже будет или конфликт (в лучшем случае) или один вариант затрет другой (в среднем) или будет полная чушня (в третьем).
И разработчик должен понимать, а что произойдет.
Миграции БД в этом случае становятся нетривиальными, подход Flyway уже не сработает, нужно выстраивать список зависимостей миграций и в рантайме опеределять их последовательность (это реально, но из стандартных средств никто так не умеет).
И так далее - много разных тонкостей и особенностей.
АС
задачи нормально надо ставить
АС
и проблемы не будет в большинстве случаев
PD
А при чем тут "нормально ставить"?
АС
две фичи, меняющие одно и тоже на разное - неверная постановка, а не проблема гита или мержа
PD
И тестируем - какие сочетания?
И если фича завершена - то нафига ее в бранче хранить? А если не завершена, то нафига ее в релиз включать?
И если фича завершена - то нафига ее в бранче хранить? А если не завершена, то нафига ее в релиз включать?
АС
а кто хранит? я разве утверждал что-то о вечном хранении? ))
АС
а включается она в релиз а) только после изолированного тестирования и б) да, специально включается рано, чтобы как можно раньше обнаружить то, о чем вы говорите - потенциальные конфликты