Git операции с репозиторием без рабочего дерева?

Question

Рабочий процесс сборки унаследованного проекта должен извлекать определенный тег версии git и компилировать эти источники.Я предложил сделать его простым и использовать Git Cli следующим образом:

git clone –b $versiontag –singlebranch $gitrepouri

вместо git clone и тега git checkout впоследствии.

Чтобы "сэкономить время", коллега хочетиспользовать другой подход = скопировать папку .git из существующего репозитория Git на другом сервере в рабочий каталог сборки, а затем работать с этой папкой.

Сначала она попыталась набрать git checkout $versiontag после копирования.
Вывод имеет несколько записей, таких как:

$ git checkout tags/sometag
D       Foobar/somefile
D       Foobar/someotherfile
[...]
Note: checking out 'tags/sometag'.

You are in 'detached HEAD' state.
[...]

, но содержимое рабочего дерева отличается от обычного git-клона и git checkout, хотя оба предполагают, что находятся в состоянии отсоединенной головы, и проверили, чтоспецифический тег.
Также были проблемы с такими инструментами, как Sonarqube, потому что git blame не работал
(Отсутствует информация о вине ..).

Впоследствии она пыталась использовать git sparse-checkout после копирования,и это, кажется, работает
с первого взгляда - хотя это намного сложнее и сложнее по сравнению с простым подходом Git Cli.

Каковы недостатки using Команды Git для репозитория Git без общего рабочего дерева?

Answer 1

Git имеет внутреннюю настройку , сообщающую , что он использует клон без рабочего дерева.В частности, core.bare должно быть установлено на true для такого хранилища.

Копирование хранилища вручную, вместо использования git clone для копирования, копирует его файлы конфигурации (.git/config и .git/info/файлы).Это включает в себя core.bare setting и несколько настроек, которые Git создает самостоятельно для описания поведения машины и файловой системы, на которой работает Git.Если эти настройки не отражают фактическую машину и фактическую файловую систему, все может пойти не так, как надоНекоторые из файлов info могут указывать Git на дополнительные каталоги , а не , скопированные;Если это так, вам нужно знать, что с этим делать.Поэтому, если вы не знаете, что делаете с этими другими переменными и info файлами, не используйте cp -r (или tar или аналогичный) для непосредственного копирования каталога .git.

Копирование необработанного .git хранилища также копирует индекс для этого хранилища.Индекс описывает рабочее дерево, поэтому скопированный индекс автоматически становится неверным, если в новом местоположении нет рабочего дерева.(Примечание: все репозитории, включая голые, имеют индекс. Индекс для изначально пустого репозитория обычно пуст, но см. Ниже.)

Тем не менее, вы можете делать некоторые Git-операции на пустом хранилище.В частности, вы можете выполнить любую операцию, которая не требует рабочего дерева.Это означает, что если вы знаете, что вы делаете в отношении специальных управляющих переменных, вы можете скопировать .git хранилище в другое место и затем использовать его.Так как вы будете избегать операций, которые используют рабочее дерево - что означает, например, избегание git checkout - сломанный индекс не проблема, хотя, если вы собираетесь быть таким умным, который, возможно, слишком умен наполовину,Вы также можете просто знать, когда можно удалить поврежденный индекс.

Вы также можете предоставить временное рабочее дерево для чистого хранилища, используя git --work-tree=<path> ... или GIT_WORK_TREE=<path> git ....Если вы сделаете это, это переопределит настройку core.bare, а индекс чистого хранилища будет использоваться для отслеживания заданного значения <path>.Обратите внимание, что если вы меняете пути, вы лишаете законной силы индекс;в этом случае вы должны либо использовать другой индекс (установив GIT_INDEX_FILE в качестве альтернативного индекса), либо удалить существующий индекс.

Таким образом, учитывая все вышеперечисленные предостережения, вы можете преобразовать каталог .git в правильный пустой Git-репозиторий или использовать cp или tar для трансплантации каталога .git, включающего или исключающего его текущее рабочее дерево, в новое местоположение с новым рабочим деревом.Но в целом вы не должны , потому что, если вы сделаете это, вы должны сделать много предположений о будущих версиях Git.Git обещает, что git clone и git bundle и т.п. будут работать так же, как сейчас;Git не обещает, что скрытая операция на скопированном каталоге .git продолжит работать так же.