Настоящая работа редко состоит из одной задачи за раз. Пока агент чинит один баг, приходит второй, а рядом ждёт мелкий рефакторинг, который просили сделать заодно. Соблазн - запустить всё это в одном и том же рабочем дереве, там, где вы сейчас стоите: окно открыто, ветка та же, переключать ничего не надо. Именно эта близость и создаёт проблему, которую потом распутывают руками.
Наивный ход понятен: раз агент и так работает с файлами проекта, пусть правит прямо в активном workspace. Кажется, что так быстрее - готовить ничего не нужно, результат сразу под рукой, diff виден в том же окне. Пока задача одна и короткая, это действительно работает и ничего лишнего не стоит.
Ломается это, как только задач становится больше одной или одна из них длинная. Агент правит те же файлы, что и вы, поверх ваших незакоммиченных изменений; два параллельных потока сливаются в один diff, и уже не сказать, где чья правка. Откатить одну задачу, не задев другую, становится отдельной работой, а активная ветка перестаёт быть чистой точкой, к которой можно вернуться.
Профессиональный механизм убирает именно это смешение. При создании сессии Devin Local предлагает выбрать, где она исполнится: в текущем workspace, в новом worktree или в существующем. Для независимой задачи предпочтителен новый worktree - изолированное рабочее дерево git, в котором агент правит свой diff, не касаясь вашей активной ветки. По завершении кнопка Merge переносит результат обратно в основной workspace. Существующий worktree выбирают, когда возвращаются к отложенной ветке; выбор делается для каждой сессии отдельно, а не один раз на проект.
Почему именно git worktree, а не отдельная копия каталога. Worktree делит с основным репозиторием один объектный store и историю, поэтому создаётся дёшево и остаётся полноценной веткой, а не снимком файлов. Несколько worktree живут бок о бок, у каждого своя рабочая директория и свой HEAD, и агент в одном из них физически не видит правок соседа. Изоляция здесь - свойство файловой системы и git, а не обещание в промпте.
У этой изоляции есть цена, и лежит она в окружении. Worktree получает только tracked files - то, что под контролем git. Локальные .env, build artifacts, установленные зависимости и прочее, что живёт вне индекса, в новом дереве могут отсутствовать, и задача, которой они нужны, честно упрётся в их нехватку. Решение - безопасный setup hook, который поднимает окружение в worktree заново: ставит зависимости, готовит конфиги, но не копирует production secrets из вашего основного дерева. Первый запуск в свежем дереве поэтому медленнее обычного - это плата за чистый старт, а не сбой.
Оправдан worktree не всегда. Для одной строки правки с очевидным diff он избыточен - там хватит Command или сессии прямо в workspace. Его зона - многошаговая независимая задача, которую не хочется вести в активной ветке: длинный рефакторинг, параллельный багфикс, эксперимент, который может и не пригодиться. Правило простое: чем больше задача способна задеть, тем раньше её стоит увести в отдельное дерево. Сомнение в независимости задачи - само по себе довод в пользу отдельного дерева.
Проверять результат нужно до слияния, а не после. Сначала прочитайте diff в самом worktree и прогоните там relevant suite - тесты, линтер, сборку. Merge не заменяет review: кнопка переносит изменения, но не решает, верны ли они. Отсюда порядок - проверка в worktree, затем merge, разрешение конфликтов и повторный прогон нужного набора уже в целевой ветке, потому что слияние могло свести вместе куски, которые по отдельности были зелёными. Практическая привычка - относиться к worktree как к маленькому pull request: его не вливают, пока diff не прочитан и проверки в нём не прошли.
Инженерный вывод из этого один: изоляция дёшева заранее и дорога задним числом. Завести worktree - секунды и одна кнопка; распутать смешанный diff из двух задач - ручная работа с риском потерять чужую правку. Дерево под задачу стоит заводить тогда, когда вы ещё не уверены, что задача независима, а не когда уже поняли, что она всё запутала.
Типичные провалы двусторонни. Первый - принять Merge за review: изменения переносят, не прочитав diff, и в целевую ветку въезжает то, что в worktree никто не смотрел. Второй - собрать окружение setup hook'ом, скопировав в него production secrets, и превратить временное дерево в место утечки. Третий - счесть, что зелёный прогон в worktree гарантирует зелёный после merge, и не перепроверить целевую ветку. Признак всех трёх общий: доверие переносу вместо проверки того, что именно перенесено.