Featured image of post В чем разница между разработкой с Git Worktree и Git Branch? Когда следует использовать Git Worktree?

В чем разница между разработкой с Git Worktree и Git Branch? Когда следует использовать Git Worktree?

На полпути к разработке новой функции и вдруг нужно срочно исправить ошибку? Раздражают беспорядок в окружении и сборочные артефакты? В этой статье рассказывается о том, как Git Worktree действует словно 'открытие филиала', обеспечивая истинную параллельную разработку и изоляцию окружений, чтобы ваш рабочий процесс не прерывался!

Вы находитесь на полпути к разработке новой функции, когда внезапно входит начальник с горящей задачей по исправлению бага. Что вы будете делать?

Большинство людей, скорее всего, использовали бы git stash, чтобы запихнуть наполовину написанный код в ящик, а затем переключились бы на другую ветку, чтобы исправить ошибку.

Но что, если ваши изменения связаны с массовыми конфигурациями окружения, или если переключение веток приводит к тому, что node_modules и Артефакты сборки (Build Artifacts) перекрестно загрязняют друг друга? Этого достаточно, чтобы захотеть разбить клавиатуру.

Вот где Git Worktree приходит на помощь!

Что такое Git Worktree?

Можно сравнить работу Git с «ремонтом дома».

С традиционным git branch, когда вы переключаете ветки, вся мебель в комнате мгновенно исчезает у вас на глазах и автоматически переставляется, чтобы соответствовать другой задаче.

Хотя это экономит место, недостатком является «загрязнение среды». Вы должны убрать грязную посуду в шкаф до того, как сможете переключиться; а после переключения в воздухе все еще может витать запах жира от предыдущих работ.

С другой стороны, Git Worktree похож на постройку идентичного дома на соседнем пустом участке.

Проще говоря, основополагающий принцип Git таков:

«Одна душа (база данных .git), множество физических тел (рабочих каталогов)».

Вы можете одновременно владеть «филиалом по разработке функций» и «филиалом по срочному ремонту». Ваша левая рука пишет логику ИИ в окне А, а правая исправляет ошибки в окне Б, и при этом стороны не мешают друг другу. Это и есть истинная параллельная разработка.

Практическое руководство по Worktree

Чтобы оставаться в потоке во время разработки, ключевое значение имеют структура каталогов и конфигурация окружения.

1. Параллельное управление каталогами: не стройте филиалы внутри штаб-квартиры

Многие люди, используя Worktree впервые, по неопытности создают новый каталог внутри исходной папки проекта. Никогда так не делайте! Это ввергнет Git в бесконечный рекурсивный беспорядок. Правильный способ создания Git Worktree:

Разместите штаб-квартиру (main) и профильный филиал (feature) параллельно друг другу.

# Запустите создание Worktree из штаб-квартиры, но поместите каталог Worktree за пределы исходного каталога проекта
git worktree add ../my-app-feat-ai dev-branch

Структура ваших каталогов должна выглядеть примерно так:

- my-project/       # Огромная упаковка
  - main-repo/      # Стабильная штаб-квартира
  - feat-ai-search/ # Новый, строящийся филиал

2. Изоляция конфигурации окружения: дайте каждому филиалу свою душу

Поскольку каталоги проектов разделены, ваши конфигурационные файлы .env также могут быть разделены.

Вы можете подключиться к тестовой базе данных в feat-ai-search, сохранив при этом исходную базу данных для разработки в main. Таким образом, при переключении окон вам даже не придется менять параметры подключения.

Зайдя в каталог Worktree, вы просто используете переменные окружения этого конкретного каталога прямо для разработки, без необходимости менять окружение или делать пересборку. Это чувство «вошел и сразу принялся за работу» поистине восхитительно.

Рабочий процесс объединения (Merge) в Worktree

После завершения разработки внутри Worktree рабочий процесс фактически идентичен традиционной ветке, с одной лишь дополнительной операцией «сноса».

Шаги рабочего процесса Описание
1. Commit и Push в филиале Вы должны физически отправиться в филиал, чтобы подтвердить изменения.
2. Проверка в штаб-квартире (Merge) Вы можете вернуться в main для объединения или сразу же открыть Pull Request (PR).
3. Элегантный снос (Remove) Как только задача завершена, не удаляйте папку напрямую; используйте команду Git для ее сноса: git worktree remove ../feat-ai-search

Бум! Временная хижина Worktree снесена, дисковое пространство возвращено, а ваша штаб-квартира снова сверкает чистотой.

Руководство по предотвращению ловушек Worktree

Хотя Worktree невероятно полезен, есть несколько подводных камней, на которые стоит обратить внимание:

Пункт Описание
Не перемещайте штаб-квартиру без разбора Потому что Worktree записывает абсолютные пути. Если вы переименуете каталог штаб-квартиры, филиал Worktree погибнет, потому что не сможет найти свою «душу».
Никакого двойного ветвления Запрещено одновременно делать проверку (check out) одной и той же ветки в двух Worktrees.
Робот-пылесос prune Если вы неловко удалите папку, используя rm -rf, не забудьте запустить git worktree prune, чтобы вычистить все оставшиеся записи в .git.

Вывод: Стоит ли прекратить использовать Git Branch?

Различные сценарии требуют различных методов разработки. Речь не о том, чтобы одно заменяло другое, а о том, что подходит больше.

Сценарий Описание
Ежедневные мелкие правки Продолжайте использовать branch; это легко и быстро.
Масштабные задачи Например, масштабный рефакторинг, изменения, затрагивающие несколько переменных окружения, или задачи, требующие долгосрочного сотрудничества с ИИ, открытие Worktree — это безусловно лучший выбор.

Git Worktree — это больше, чем просто команда; это мощный инструмент, помогающий нам поддерживать рабочий поток разработки. В следующий раз, когда вы столкнетесь с громоздкой, масштабной задачей, попробуйте открыть изолированный «филиал Git Worktree» и ощутите беспрепятственный процесс разработки, как никогда раньше!

Reference

All rights reserved,未經允許不得隨意轉載
Создано при помощи Hugo
Тема Stack, дизайн Jimmy