Что такое Git worktrees и зачем их использовать

Перевод статьи Cassidy Williams из GitHub Blog, оригинал: https://github.blog/ai-and-ml/github-copilot/what-are-git-worktrees-and-why-should-i-use-them/

Git worktrees позволяют держать несколько рабочих копий одного репозитория на разных ветках — и сейчас эта возможность в тренде. Забавно, что в Git она появилась ещё в 2015 году. Но worktrees действительно удобны, и в этой статье разберёмся, зачем они нужны, чем отличаются от обычных веток и почему внезапно стали популярны.

Переключение контекста через ветки и stash

Представьте: вы работаете над задачей и вдруг получаете срочный баг. Нужно срочно переключить контекст.

Сначала, скорее всего, спрячете текущие изменения в stash:

			git stash "wip feature login"
		

Потом перейдёте на main и обновите её:

			git checkout main 
git pull origin main
		

Затем создадите ветку с хотфиксом:

			git checkout -b hotfix-bug
		

Пофиксите, закоммитите и запушите ветку:

			git add . 
git commit -m "fix broken submit button" 
git push origin hotfix-bug
		

После слияния pull request вы вернётесь к компьютеру, подтянете main и удалите ветку с багфиксом:

			git checkout main 
git pull origin main 
git branch -d hotfix-bug
		

А потом сможете вернуться к задаче, над которой работали:

			git checkout feature-login 
git stash pop
		

Фух. На чём мы остановились?

Переключение туда-сюда, перезагрузка файлов, переустановка node_modules в зависимости от того, что изменилось, — всё это отнимает много сил. Нагрузка от смены контекста серьёзная.

Это базовый пример, но иногда разработчики справлялись с таким хаосом сложными командами git stash или даже несколькими клонами одного репозитория (я сама грешила этим).

А потом появились… worktrees!

Переключение контекста через worktrees

С worktrees вы никогда не покидаете свою ветку и не используете stash, а редактор с вашей текущей фичей остаётся нетронутым.

			git worktree add ../hotfix-workspace -b hotfix-bug main
		

Эта команда мгновенно создаёт соседнюю папку hotfix-workspace, базирует её на main и создаёт новую ветку hotfix-bug.

Теперь можно открыть эту папку в новом окне редактора (или перейти в неё через cd) и чинить баг. Исходное окно редактора остаётся в том же состоянии, в котором вы его оставили.

			cd ../hotfix-workspace 
# ...fix fix fix... 
git add . 
git commit -m "fix broken submit button" 
git push origin hotfix-bug
		

Pull request сливаете онлайн, как обычно, а после слияния можно просто удалить временную папку.

			cd ../main-project 
git worktree remove ../hotfix-workspace
		

Гораздо плавнее! Нет риска конфликтов stash, редактор не перезагружается, и вы действительно можете работать параллельно.

Так почему же сейчас?

Долгое время worktrees были относительно неизвестны. Большинство разработчиков никогда о них не слышали, потому что либо Git GUI не поддерживали их (или относились как к второсортной функции), либо все привыкли к знакомой схеме: feature-ветка, работа, PR, merge и повтор.

Сейчас наша работа изменилась. ИИ заставляет нас работать параллельно больше, чем когда-либо в истории разработки ПО. Разработчики запускают множество сессий одновременно, а «культура код-ревью» растёт быстрее, чем «культура написания кода».

Агенты и люди могут делать больше параллельно с помощью worktrees. Это режим по умолчанию в приложении GitHub Copilot и во многих других современных инструментах.

Агенты и люди могут делать больше параллельно с помощью worktrees.

Cassidy WilliamsSenior Director for Developer Advocacy at GitHub

В чём подвох?

Worktrees решают кучу проблем, но есть нюансы, на которые стоит обращать внимание.

• Раздувание зависимостей: каждая папка worktree требует собственную копию зависимостей проекта. Если запускать npm install или pip install в нескольких worktrees, диск может быстро закончиться.
• Управление папками: нужно удалять папки worktree, чтобы со временем не засорять родительский каталог. Приложение GitHub Copilot часто делает это за вас, но если вы работаете в терминале, придётся следить самостоятельно.
• Требования к глобальному .gitignore: если создавать worktree внутри основного репозитория, их нужно вручную добавить в .gitignore, чтобы случайно не закоммитить. Можно создавать worktree за пределами основного репозитория (GitHub Copilot делает это по умолчанию), но это стоит учитывать.
• Ограничение «одна ветка»: Git не позволяет одновременно checkout’ить одну и ту же ветку в двух разных worktrees, чтобы избежать повреждения данных.

Как использовать git worktrees в приложении GitHub Copilot?

Отличный вопрос! Здорово, что там всё работает «из коробки». Когда вы открываете приложение, на главном экране есть выпадающий список, который спрашивает, где запускать новую сессию. По умолчанию выбран новый worktree.

Когда вы запускаете новую сессию, можно нажать на имя сессии вверху приложения и увидеть (забавное!) сгенерированное имя вашего worktree, а также путь, где он находится, проект, для которого он создан, и сведения о внесённых изменениях.

Проще простого!

Стоит ли использовать worktrees?

Я дам вам самый senior-ответ, который только можно: зависит от ситуации! Вам может быть удобнее работать по-другому. Возможно, вы не так много работаете параллельно и привыкли к ментальной модели веток и stash. Возможно, теперь вы будете использовать только worktrees. А может, захотите и то, и другое!

Мир у ваших ног, и попробовать всё это можно уже сегодня в приложении GitHub Copilot.

Об авторе. Cassidy Williams — старший директор по адвокации разработчиков в GitHub. Она создаёт ПО, консультирует стартапы и учит разработчиков строить лучше. Подписаться на её еженедельную рассылку можно на cassidoo.co/newsletter.

Выводы

Git worktrees — способ работать с несколькими ветками одновременно, не прерывая текущую задачу и не рискуя запутаться в stash. Они особенно удобны при параллельной работе с ИИ-агентами и встроены в приложение GitHub Copilot по умолчанию. Попробуйте — возможно, именно они упростят ваш рабочий процесс.