"⚪️ Агентный git flow, часть 3: а где же human? После реализации всего вышеописанного, оказалось, что разработка проекта закуклилась внутри оркестратора. Я просто даю задачи, и получаю результат. Вроде бы не плохо! Но мне это показалось слишком радикальным, ведь хочется иногда в режиме ""ручного"" управления что то доработать! Ну - агентом, конечно, но под управлением. Хотя бы иметь такую возможность. Это прекрасно что агенты в своих рабочих деревьях чего то пилят сбоку. Но хотелось прям вот тут, в оригинальном чекауте проекта, иметь возможность тоже чего то впилить. В общем, нужна локальная `dev` ветка. Вот ее я правильно прикручивал дольше всего. Выяснилось, что мои корявые правки вечно все ломают. То они конфликтуют с . То куча проблем возникает с мержем моих правок в origin/develop, потому что оркестратор туда уже успел напихать много чего. И что обидно - свои конфликты он автоматом как правило решает, а мне мою работу мержить нужно каждый божий раз руками. Непорядок. Первая мысль возникла - отправлять мои правки в ту же мерж очередь, и пускай оно туда впиливается! типа - заслал, оно вмержилось. Но есть ограничение - нельзя трогать dev пока правки не влились. И тут выяснилось, что ждать очереди - это дискомфортно, бывает долго и скучно. Следующая идея: закидывать в очередь последний коммит. Типа, сделал в dev коммит с правками, вот его пускай именно его ""завозят"" в origin/develop. Правда, быстро выяснилось, что одного коммита - мало, и надо бы цепочку коммитов кидать. Схема вышла норм: цепочки заезжают норм. Ну и дополнительные хлопоты возникли с тем, что ""моя"" ветка dev предполагалась ""долгоживущей"". Фичабранчи создаются под задачу. А вот dev ветку я не планировал регулярно менять - следовательно, появилась необходимость регулярных подтягиваний базы dev ветки на текущее состояние origin/develop. Для реализации пришлось сделать отдельный небольшой тулинг. * Мои изменения отправляет `dd-flow dev add-merge`: берет из ветки dev все невмерженные в origin/develop коммиты, и засылает их ""трамвайчиком"" в общую очередь мержей. * Другой тул `dd-flow dev sync --dev`: делает ""обратный мерж"" - вливает изменения из origin/develop в dev, попутно решая конфликты. То есть такая ""очередь мержей"" для одной ветки, и в обратном направлении. Команда похожа на dev sync, но только названием - внутри там совсем другая логика, и она реализована через вызов оркестратора и специального флоу под хту задачу dev-sync. Так организовалась работа с human in the loop."