Cначала о проблеме, которую она решает.
Сидите вы, примус починяете очередную фичу в EDT пилите. И вдруг появляется необходимость переключиться на другую ветку и что-то там поделать. EDT в такие моменты говорит нам:
А оно не быстренько. Бесит.
И это, к слову, не только про EDT касается и тех, кто сидит в конфигураторе без EDT. Частое переключение между ветками и там не без веселья: медленная выгрузка/загрузка изменений. Хорошо ещё если собираете базы вы автономным сервером и прокатила инкрементальная сборка. Привет, Дима, можешь не писать про MVP. 😉
Самое простое “решение” — отдельный клон.
Клонировал репозиторий ещё раз, завёл ветку, подключил в EDT, поработал, всё удалил. Работает, но: место не резиновое, ведь и сам проект, и всё дерево .git продублированы, да и клонирование не моментальное, а копипастить репозиторий — западло, да и там ещё пачка барахла в build прицепом скопируется. В общем — не кошерно.
Но есть Git Worktree.
Одной командой git worktree add создаётся отдельный каталог, привязанный к тому же репозиторию. В нём живёт своя ветка. Поработал — удалил по завершении работы. Каталог .git общий, место экономится неплохо. Создание и удаление — быстрые. Максимум один раз на инициализации ветки подождём пока EDT впитает проект. Как будто бы кошерно.
Как я это использую.
На данный момент я работаю на связке OpenCode + OpenChamber. OpenChamber из коробки умеет работать с worktree, буквально одной кнопкой поднимается каталог под новую ветку. Правда, не обошлось без ложки дёгтя — нативной поддержки worktree в EDT, увы, нет. Но это не сильно тяготит, можно либо руками импортировать один раз проекты, либо заскриптоваться на edtcli (а также можно, например mcp bslls инициализировать при создании worktree).В общем проблема параллельной работы над разными фичами довольно элегантно закрывается с помощью git worktree. А с переходом на llm powered разработку особенно важна параллельность работы. Век живи, век учись, как говорится. 😎