Вы можете использовать архиватор (tar или любой другой) для сбора всего состояния репозитория и рабочего дерева и копирования его в какую-то другую область файлового дерева:
cd /path/to
tar cf - repo | (cd /different/path; tar xf -)
для экземпляров экземпляров все дерево файлов от /path/to/repo до /different/path/repo. Это копирует и сам репозиторий - все файлы в .git - и рабочее дерево (все файлы, которые не в .git).
Есть несколько предостережения здесь. Наиболее важным является то, что .git под верхним уровнем рабочего дерева должен действительно быть каталогом, содержащим репозиторий, а не просто файлом, подобным тем, которые созданы git worktree add.
Используя in- Git методы, такие как git clone, не будут работать: они копируют только репозиторий . Рабочее дерево не является частью репозитория:
За исключением копирования всего каталога каждый раз, когда мне нужна эта функциональность, я не могу думать, как это сделать.
Это потому, что Git буквально не будет делать это. Рабочее дерево - ваше рабочее дерево - ваше , а не Git, и оно не является частью репозитория Git. Это просто рядом с хранилищем, которое находится в подкаталоге .git.
Если у вас есть Git 2,5 или более поздняя версия, предпочтительно 2,15 или более поздняя, поскольку существует довольно неприятная ошибка в этом до тех пор 1 - что бы вы ни думали о том, чтобы поступать так, вероятно, лучше обработать через git worktree add. Это создает отдельное рабочее дерево, которое снова принадлежит вам, а не Git, в котором Git делает git checkout некоторого коммита или ветки по вашему выбору во время запуска git worktree add. Это второе рабочее дерево не имеет свой собственный репозиторий: оно использует исходное рабочее дерево, создавая файл с именем .git вместо каталога с именем .git.
(Фактический репозиторий получает в момент git worktree add много файлов состояний для отслеживания существования этого добавленного рабочего дерева. Для добавленного рабочего дерева требуется добавить новый индекс, новый HEAD и т. Д. все они выделены для нового рабочего дерева и отделены от индекса и HEAD и т. д. для основного рабочего дерева, которое все еще находится рядом с основным репозиторием. Обратите внимание, что если вы позже скопируете реальный репозиторий используя вышеупомянутый трюк tar, он все равно будет думать, что у него есть эти добавленные рабочие деревья. Если они все еще существуют, это нормально, если нет, git worktree prune заставит скопированное хранилище обновить свое представление о том, как выглядит внешний мир. )
1 Ошибка заключается в том, что git gc не удалось найти добавленные HEAD, индекс и такие файлы. Это означает, что если вы:
- используете отдельный HEAD в добавленном рабочем дереве и делаете новые коммиты, они удаляются (!) И
- , даже если вы не Если вы используете
git add обновленные файлы, но не делаете коммит, вы можете удалить любые новые объекты BLOB-объектов уровня хранилища (!)
, что приведет к путанице.
Стандартный 14-дневный льготный период по умолчанию означает, что если вы выполнили всю свою работу в течение 14 дней, а затем отказались от добавленного рабочего дерева, эта ошибка никогда не ударит вас, поэтому, если у вас версия Git ниже 2.15, вы можно безопасно использовать git worktree add, если вы все сделаете в добавленном рабочем дереве в течение двух недель.
(хотя на самом деле ошибка меня поразила. К счастью, добавленное рабочее дерево было просто эксперимент, от которого я отказался, но не удосужился его удалить, и я смог все почистить.)