Использование 'git pull' vs 'git checkout -f' для развертывания сайта
Я нашел два общих подхода к автоматическому развертыванию обновлений веб-сайта с помощью открытого удаленного репо.
Первый требует, чтобы репо было клонировано в корень документа веб-сервера, а в крюке после обновления используется git pull.
cd /srv/www/siteA/ || exit
unset GIT_DIR
git pull hub master
Второй подход добавляет "отдельное дерево обработки" в голый репозиторий. Крюк post-receive использует git checkout -f для репликации хранилища HEAD в рабочий каталог, который является корнем документа webservers, т. Е.
GIT_WORK_TREE=/srv/www/siteA/ git checkout -f
Первый подход имеет то преимущество, что изменения, внесенные в рабочий каталог веб-сайтов, могут быть зафиксированы и возвращены к общему репо (однако файлы не должны обновляться на реальном сервере). Второй подход имеет то преимущество, что каталог git не находится внутри корня документа, но это легко решить с помощью htaccess.
Является ли один метод объективно лучше другого с точки зрения лучшей практики? Какие еще преимущества и недостатки мне не хватает?
Ответы
Ответ 1
В период управления выпуском (здесь развертывание) лучше всего иметь целевую среду, которая не зависит от механизма выпуска.
Другими словами, второе решение (checkout -f) изменит структуру обычного веб-каталога без каких-либо других подкаталогов, которые не должны быть частью его (например, папки .git).
Я использую его, например, в " использовании git для развертывания моего приложения node.js на моем производственном сервере ".
Это минимизирует любой побочный эффект и позволяет рабочей среде работать с тем, что нужно для запуска, без помех.
