Это использует Git в качестве инструмента развертывания, что немного похоже на использование гаечного ключа в качестве молотка: он работает, но есть веские причины не делать этого.
Продолжительность:
git --work-tree=/location/ --git-dir=/source.git/ checkout -f
очень похож на бег:
git checkout -f
Я предполагаю, что вы уже привыкли использовать git checkout с именем ветви для проверки конкретной ветви. Если вы обратитесь к документации git checkout , вы увидите, что вы также можете запустить git checkout без имени ветви:
Вы могли бы опустить branch ;, в этом случае команда вырождается, чтобы «проверить текущую ветку», что является прославленным запретом с довольно дорогими побочными эффектами, чтобы показать только информацию отслеживания, если существует, для текущей ветви.
То есть, если данный конкретный репозиторий в настоящее время находится на ветке master, запуск git checkout означает git checkout master, который уже включен. Итак, теперь давайте обратим внимание на опции --git-dir и --work-tree - что означает просмотр документации по интерфейсу git команды . Наиболее важной частью на самом деле является опция --work-tree, потому что параметр --git-dir уже установлен тем, что он работает как Git-хук (хуки Git запускаются с предустановкой $GIT_DIR):
--work-tree=<em>path</em>
По сути, это говорит Git: не ищите рабочее дерево в обычном месте, где бы оно ни находилось, ищите в этом другом path месте . В «чистом» Git-репозитории (на веб-сервере) обычно сам Git-репозиторий настроен так, чтобы иметь рабочее дерево no вообще. Поэтому вы должны использовать --work-tree (или что-нибудь эквивалентное), чтобы заставить Git предположить, что этот другой каталог, такой как /location/, содержит извлеченный репозиторий.
Глагол checkout затем говорит Git взять все, что находится в текущем рабочем дереве (в этом другом месте), и повторно проверить текущую ветку, какой бы ни была текущая ветка (вероятно, master). Опция -f - это опция git checkout, и она означает force , что означает: Даже если эта проверка забьет некоторые незавершенные работы, сделайте это в любом случае. Обычно git checkout старается не перезаписывать текущую работу.
Конечно, на вашем веб-сервере не должно быть незавершенного процесса: файлы в месте развертывания, вероятно, должны соответствовать тому, что Git считает, что они есть. Таким образом, -f должен обычно быть ненужным. Тем не менее, сама идея того, что Git считает рабочим деревом , сама по себе является проблемой. Git отслеживает рабочего дерева через то, что Git называет его index . Если вы слишком настойчиво продвигаете идею развертывания, используя сам Git в качестве инструмента развертывания, вы обнаружите, что отслеживание Git нарушает развертывание. Это , почему это все равно, что использовать гаечный ключ в качестве молотка: он работает, если вы применяете его достаточно аккуратно, или знаете, что делаете, и осторожны, но если вы делаете много ударов, гаечный ключ может сломаться.
Для статьи про Git-as-deploy-tool, в которой рассматриваются некоторые из обоих аргументов, см. https://www.freelock.com/blog/john-locke/2015-06/case-git-deployment-tool. См. Также Развертывание кода с помощью GIT - проверка против сброса --hard? и git post-receive hook не обрабатывает и другие ветви .