GitHub опубликовал разбор того, как использовать Git worktree для параллельной разработки и почему этот механизм стал популярным только сейчас, несмотря на то, что появился в Git ещё в 2015 году.
В классическом рабочем процессе разработчик переключается между ветками в одном локальном клоне репозитория. При внезапном баге приходится откладывать текущую задачу, переходить на main, обновлять код, править ошибку, создавать и пушить ветку, ждать слияния pull request, затем снова тянуть main, удалять временную ветку и возвращаться к исходной задаче. Это сопровождается перезагрузкой файлов, потенциальной переустановкой зависимостей и высокой нагрузкой на внимание.
Раньше некоторые разработчики пытались смягчить это с помощью git stash или нескольких клонов одного репозитория, что усложняло работу. Git worktree предлагает альтернативу: отдельные рабочие каталоги, привязанные к разным веткам одного репозитория, без необходимости стэшить изменения и постоянно переключать ветки.
В примере GitHub показано, как при использовании worktree основной рабочий каталог с исходной задачей остаётся нетронутым. Для срочного бага создаётся новый рабочий каталог, например hotfix-workspace, основанный на ветке main с новой веткой hotfix-bug. Разработчик открывает эту папку в отдельном окне редактора, исправляет ошибку и после слияния pull request просто удаляет временный каталог.
Такой подход снижает риск конфликтов при использовании stash, убирает перезагрузку основного редактора и позволяет действительно работать параллельно. При этом привычный цикл ветка → работа → pull request → merge сохраняется, но организуется через несколько рабочих каталогов вместо постоянных переключений в одном.
По оценке GitHub, долгое время worktree оставались малоизвестными. Их редко поддерживали графические клиенты Git или делали это с ограничениями, поэтому большинство разработчиков придерживались классической схемы с одной локальной копией и ветками.
Ситуация меняется вместе с ростом количества параллельных задач и распространением ИИ-инструментов. В GitHub отмечают, что GitHub Copilot и другие современные инструменты поощряют одновременную работу над несколькими ветками и задачами, а культура ревью кода усиливается и нередко выходит на первый план по сравнению с написанием кода.
Worktree стали стандартным режимом в приложении GitHub Copilot. При запуске нового сеанса на стартовом экране приложения предлагается выбрать, где его запустить, и по умолчанию создаётся новый рабочий каталог. В интерфейсе можно увидеть сгенерированное имя worktree, путь к нему, проект, к которому он относится, и информацию об изменениях.
GitHub подчёркивает, что выбор подхода остаётся за разработчиком: можно продолжать работать только с ветками и stash, перейти полностью на worktree или комбинировать оба метода. Платформа даёт возможность протестировать все варианты в приложении GitHub Copilot.
Материал подготовлен старшим директором по работе с разработчиками GitHub Кэссиди Уильямс. Она занимается разработкой ПО, консультирует стартапы и обучает разработчиков. У неё есть еженедельная рассылка cassidoo.co/newsletter с обновлениями, задачами по программированию и шуткой для подписчиков.
В публикации также упоминаются дополнительные ресурсы GitHub: руководство по работе с GitHub из VS Code, обзор нововведений Git 2.54, вводный материал по GitHub Copilot CLI, новый датасет для поиска многоязычного контента в репозиториях, а также аналитические и обучающие материалы по RAG, DevSecOps и лучшим практикам корпоративной разработки.
Источник: GitHub
