Git Post-receive крюк с частью рабочего дерева

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

Обычно я рекомендовал бы использовать somekind инструмент непрерывной интеграции для работы. Один возможный рабочий процесс, который я мог бы использовать сам, был бы

• Храните файлы тем в публичном репозитории GitHub. Это бесплатно, вероятно, нет больших секретов в исходном тексте вашей темы, а в качестве дополнительного бонуса вы можете даже открыть исходную тему.
• Настройте задание CI с Travis CI для вашего репозитория. Вы в основном получаете экземпляр бесплатной сборки в облаке, и вы можете делать всевозможные вещи до или после сборки. Вы могли бы, например. запустите gulp build (или независимо от имени вашей задачи), поэтому вам не нужно будет хранить каталог build в репозитории git вообще.
• В Travis after_success вы можете скопировать каталог сборки на целевой сервер, например, с помощью scp. Вот пример того, что нужно делать с FTP. Travis поддерживает шифрование конфиденциальных данных, поэтому вам не нужно беспокоиться (по крайней мере, так много) о сохранении имени пользователя и пароля в git репо.

Этот поток полезен, когда вы хотите развернуть сборку каждый раз, когда вы что-то передаете в репозиторий git.. Кстати, когда вы впервые используете его, это действительно похоже на магию: "Я просто сделал это git push, и теперь изменение уже работает на моем сервере."

Однако вы упомянули, что хотите развернуть код на сервере тестирования. Это правда, что инструменты CI (такие как Travis) могут использоваться для поддержания потока между различными этапами развертывания, из которых многие тестируют серверы. Один пример потока для больших проектов может быть

development -> tests passing? -> release -> tests passing? -> integration -> tests passing? -> staging -> tests passing? -> production

... где поток может быть частично или полностью автоматизирован с помощью инструмента CI.

Однако вы сделали это так, как в вашем случае развертывание сборки - это однообразная вещь, которую вы иногда просто хотите сделать вручную. (Приносим извинения, если я неверно истолковал вас.) Для такого рода одноразовых задач использование сценариев оболочки или инструментов управления задачами является более подходящим.

Вы упомянули, что уже используете gulp. Это очень удобный инструмент для работы, особенно потому, что вы можете легко комбинировать разные "потоки задач". У вас может быть одна задача для создания темы (gulp build) и другая для развертывания тестового сервера (gulp deploy-test), которая просто расширяет задачу build с дополнительным шагом для копирования файлов на тестовый сервер. gulp-scp выглядит как прекрасный плагин для задачи (я не использовал его сам, хотя это был только первый результат поиска из Google). Если это не сработает, вы всегда можете вызвать scp вручную с помощью gulp-shell или аналогичного.

Вы даже можете параметризовать задачи развертывания, чтобы вы могли сделать что-то вроде: gulp deploy --test и gulp deploy --production

Там вы идете, это был ваш первый урок в devops. Там есть целый мир вещей, чтобы узнать, насколько вам интересна эта автоматизация задач в программных проектах.