Есть ли способ отсоединить и прикрепить рабочие деревья git?

Question

Есть ли способ отсоединить и прикрепить рабочие деревья git?По сути, мне бы хотелось иметь следующий рабочий процесс:

1. Создать рабочее дерево
2. Отключить рабочее дерево после выполнения некоторой работы (добавления коммитов), каталог не должен быть удален
3. оформить ветку рабочего дерева в моей основной проверке.
4. сделать push / linting / push на сервер компании.
5. заново присоединить рабочее дерево и, если необходимо, продолжить работу с существующим каталогом

Чтобы объяснить мои аргументы в пользу моего рабочего процесса ... У меня есть куча настроек, которые связаны с путем к основному хранилищу проверки ... это включает проверки linting / pre-commit и некоторые другие рабочие процессы (настройкаэто сложно, и я не знаю деталей) ... что я хотел бы в идеале сделать следующим переключением от git worktree к основному месту проведения репо в репо .... похоже на то, как выбудет переключаться между ветвями.

например, я делаю следующее

1. создать ветку A рабочего дерева в директории A
2. сделать некоторые правки * разблокировать 1023 *
3. ""worktree A
4. контрольная ветвь Ветвь в главном контрольном каталоге
5. выполняет операцию linting / pre-check (они не редактируют ни один файл в ветви)
6. главная ветвь checkoutв главном каталоге проверки
7. вернуться к редактированию рабочего дерева A в каталоге A

Answer 1

Подкоманда lock (git worktree lock) существует специально для того, чтобы основной репозиторий не считал рабочее дерево «пропавшим», если добавленное рабочее дерево включено, например, флэш-накопитель, который не всегда монтируется.Вариант использования здесь:

• вставка флэш-накопителя, монтирование файловой системы
• добавление рабочего дерева на флэш-накопитель, использование его на некоторое время
• блокировка работыДерево и удалить (размонтировать и отключить) флэш-накопитель
• позже, заново вставить флэш-накопитель, разблокировать дерево работы, продолжить работу

, который все на одном компьютере с одним основным хранилищем.Непонятно, если это то, что вы имели в виду, или если вы имели в виду:

• вставить флэш-накопитель и смонтировать файловую систему
• добавить рабочее дерево на флэш-накопитель, использовать, заблокировать, размонтировать/ удалить диск
• вставить флэш-диск на другой компьютер (назовем это machine-X), у которого есть отдельный клон того же origin репо
• use thumb-управляйте рабочим деревом (с соответствующей блокировкой / разблокировкой при извлечении флэш-диска, чтобы файлы администрирования не исчезали)

Это может работать, но имеет некоторые проблемы.Во-первых, не существует формального способа сказать Git: «это рабочее дерево, которое я никогда не создавал для этого хранилища, внезапно теперь существует, пожалуйста, добавьте его».Однако, если вы использовали git worktree add для создания рабочего дерева в том месте, где рабочим деревом флэш-диска будет , а затем установите флэш-накопитель в этой области (возможно, после удаления рабочего дерева).само по себе без знания Git), это будет работать при ограничении или двух.

В частности, когда вы находитесь в добавленном рабочем дереве:

1. HEAD и индексфайлы для этого рабочего дерева на самом деле находятся внутри основного репозитория.
2. Каждый раз, когда вы git add файл копируете его в индекс, не только обновляется сам индекс в главном репозитории, но и базовый объект Git.также входит в основной репозиторий.

Следовательно, вам придется также перенести содержимое этих файлов - для каждого рабочего дерева HEAD и индекса, плюсбазовые объектные файлы Git - если вы когда-нибудь измените их содержимое, которое они имеют сразу после git worktree add.Если нет, то git worktree add, который вы делаете на machine-X, один раз, чтобы настроить что-то перед тем, как вы переключитесь в дерево работы с флэш-накопителем, будет достаточно.

(Обратите внимание, что если вы делаете Запустите git add или измените HEAD, базовые объекты репозитория небезопасны в версиях Git до 2.15.0, где это было исправлено. По сути, основное рабочее дерево может получить их после истечения срока действия сокращения по умолчанию, обычно 14 дней.Краткая версия этого предупреждения сводится к тому, что «не держите добавленные рабочие деревья в использовании более двух недель», хотя это немного излишнее обобщение. Слегка связано: переименование веток, которые могут быть в добавленных рабочих деревьях, содержит ошибки в версиях Gitдо 2.15.0.)