Несколько рабочих деревьев

Одна папка неудобна, когда нужно одновременно редактировать новый вариант каталога и читать прежнюю выбранную версию. Постоянное переключение ветки меняет файлы под редактором и может смешать контекст задач. Git позволяет создать несколько рабочих деревьев, связанных с одним хранилищем истории.

Рассмотрим git worktree на учебном каталоге. Сценарий lesson-17 архива задаёт исходный проект с тегом catalog-v0.1.0 и две новые соседние папки. Они подготовлены только как инструкция; рабочие деревья и коммиты не создавались. Не применяйте сценарий к действительной папке ProfessorWeb.

История общая, файлы разные

В предыдущем уроке тег обозначал согласованный снимок, а main уже содержал следующую заметку README. Теперь хотим читать тег в одной папке, а в другой менять отступы текущего каталога. Исходная папка остаётся основным рабочим деревом.

У связанных деревьев общая история и многие ссылки, но собственные рабочие файлы, индекс и положение HEAD. Поэтому незаписанное изменение CSS в новой папке не появится автоматически в старой. При этом сохранённый коммит станет известен общему репозиторию. Это сочетание позволяет разделить файловый контекст, не создавать независимую копию всей истории для каждой небольшой задачи.

Для чтения выбранной версии добавим дерево с отделённым положением HEAD:

git worktree add --detach ../catalog-review catalog-v0.1.0

Ожидается папка catalog-review со снимком тега. Здесь мы только читаем файлы, поэтому новая ветка не нужна. Не начинайте в этом дереве обычную длительную разработку без явного назначения ветки: результат чтения и место хранения новых записей должны быть понятны заранее.

Руководство worktree описывает связанные деревья и ограничения веток. Для нашей модели полезна конкретная граница: обычно одна ветка не открывается одновременно в нескольких связанных рабочих деревьях. Поэтому отдельной задаче дадим отдельное имя.

Папка новой задачи

Создайте второе дерево с новой веткой от текущего main:

git worktree add -b feature/catalog-spacing ../catalog-spacing main
git worktree list

Ожидаются основная папка, catalog-review на теге и catalog-spacing на новой ветке. Список показывает пути и текущие положения. Перед изменением всегда сверяйте нужную папку: похожие имена окон редактора могут скрыть то, что вы открыли старый снимок вместо новой задачи.

В catalog-spacing/public/theme.css измените только padding каталога с 1rem на 1.5rem. URL и содержание Markdown сохраняются. Прочитайте статус именно в этой папке, затем сохраните CSS отдельным коммитом. В статье пути к соседним папкам относительны исходной лаборатории; если вы уже внутри другого дерева, сначала определите текущий каталог.

git -C ../catalog-spacing status --short
git -C ../catalog-spacing diff -- public/theme.css
git -C ../catalog-spacing add public/theme.css
git -C ../catalog-spacing commit -m "Увеличить отступ учебного каталога"

После записи ожидается чистое дерево новой задачи. В основной папке main всё ещё имеет прежний CSS, поскольку мы не объединяли ветку. В дереве чтения тег тоже остаётся прежним. Общая история знает новый коммит, но положение каждого дерева определяет, какие файлы сейчас представлены на диске.

Чтение версии без переключения редактора

Откройте content/courses.md в дереве catalog-review. Там ожидается согласованный каталог из тега. Прочитайте рядом CSS и сравните его с новой папкой. Для нашей задачи различается отступ; обе ссылки совпадают. Это сравнение не требует сначала убрать незаписанные файлы из одного редактора и переключать его на другую версию.

Не считайте это изоляцией всей среды. Если два дерева используют одинаковый внешний каталог сборки, одну базу, общий порт сервера или настройки профиля браузера, они могут мешать друг другу. Worktree разделяет рабочие исходники, но назначение внешних ресурсов остаётся отдельным решением.

В учебном сценарии серверы вообще не запускаются. Если позднее показывать обе версии локально, каждой потребуются своя папка результата и отдельный адрес. Запись такого условия в README помогает коллеге понять, почему файлы разделены, а состояние сети не обязательно разделилось вместе с ними.

Также в связанных деревьях существуют особенности служебных путей. Не переносите папку вручную как независимый архив .git и не копируйте её служебный файл в другой проект. Управляйте созданием и удалением через предназначенные операции. Для передачи исходников используйте явно подготовленный набор файлов или обычный отдельный репозиторий.

Одновременно открытые редакторы полезно подписать по роли: чтение версии и новая задача. Даже при разных путях похожие окна создают риск сохранить правку в неожиданном месте. В учебном дереве чтения мы вообще ничего не записываем, поэтому любой изменённый файл там становится поводом сначала выяснить происхождение. Если вы обнаружили нужную идею именно при чтении тега, перенесите её в назначенную рабочую задачу и прочитайте соответствующее различие. Так выбранная старая версия остаётся понятным источником сравнения. Список worktree помогает увидеть пути, но не знает редакционного назначения ваших окон. Назначение должно быть частью рабочего договора. После удаления временной папки в описании задачи достаточно сохранить имя ветки и смысл коммита; случайный абсолютный путь чужого компьютера не становится обязательным условием продолжения. Новая рабочая папка сможет представить ту же записанную историю позднее.

Завершение временной папки

После сохранения задачи и чтения версии обе дополнительные папки больше не нужны. Сначала убедитесь, что в них нет незаписанной работы и новых неотслеживаемых материалов. В нашей модели CSS уже записан, а дерево чтения не менялось. Тогда можно удалить связанные рабочие деревья штатно:

git worktree remove ../catalog-review
git worktree remove ../catalog-spacing
git worktree list

Ожидается только исходное дерево в списке. Ветка feature/catalog-spacing и её коммит сохраняются в истории; удаление файловой папки не является удалением задачи. Для дальнейшего ревью можно прочитать эту ветку из основной лаборатории или создать дерево заново.

Если Git отказывается удалить папку из-за правок, сначала разберитесь с ними. Принудительное удаление ради чистого списка может потерять незаписанный материал. Для большого редакционного проекта это особенно неприятно: полезный черновик мог существовать только в одном рабочем дереве.

У нашей задачи ожидаемый итог состоит из записанного изменения CSS в отдельной ветке и сохранённого тега для чтения прежней версии. Основной main не объединён автоматически. Мы отделили два файловых контекста, сохраняя понятную общую историю. В следующем уроке перейдём к отдельному локальному учебному сайту и проследим CSS-правило до видимого компонента.