Ответ 1

Не с Git

Git не предназначен для загрузки только определенных файлов или каталогов. Это ориентированный ациклический граф с бинарными блоками как объекты, а иногда и несколькими объектами, которые уплотняются в один более крупный объект.

Благодаря дизайну Git ваш конкретный запрос невозможен.

Альтернативы

крюк после приема

Если ваш веб-сайт содержит только простые статические файлы, тогда вы можете нажать на репозиторий Git через SSH. В действительности, вряд ли ваш репозиторий будет большим, если у вас нет нетекстовых файлов.

Возьмем, например, следующую настройку.

• /var/lib/www - веб-каталог apache, который является клонированной копией www.git
• /var/lib/www.git - голый репозиторий Git.
• /var/lib/www.git/hooks/post-recieve - крюк на стороне сервера Git. Это может быть оболочка script, которая извлекает репозиторий www, когда этот репозиторий обновляется.

Пример post-recieve hook script:

#!/bin/bash
cd /home/sam/sandbox/git-hooks/www
unset GIT_DIR
git fetch origin master
git reset --hard origin/master

Zip up build в tar.gz

В конце сборки вы можете заархивировать свои файлы в tar.gz. Этот файл должен быть размещен где-нибудь (возможно, выпуски GitHub, если вы используете GitHub). Некоторые предприятия используют при размещении артефактов, таких как Nexus или Artifactory.

Идея заключается в том, что у вас есть проверенный артефакт, который имеет определенный sha256sum. Артефакт, который вы тестируете, является тем же артефактом, который в конечном итоге идет на производство.

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

Ответ 2

Нет лучшей практики.

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

Какова наилучшая практика?

Существует ряд инструментов, которые можно использовать для обработки ваших развертываний. Большинство инструментов, как правило, позволяют настроить ряд шагов, которые позволяют развернуть код, который вы хотите, в нужную вам среду. Вы можете использовать простые инструменты, такие как Phing или Deployer в мире PHP, или что-то более сложное, как Puppet или Chef, если у вас более сложные потребности. Вы могли бы просто написать свои собственные сценарии bash, если вам действительно очень просто. Я рекомендую Phing или Deployer предоставить информацию, которую вы предоставили. https://deployer.org/ https://www.phing.info/

Вы просто сконфигурируете любой инструмент, который вы хотите передать в целевое поле, и скопируйте только те файлы, которые вы хотите, в каталог, который вы хотите на сервере, каким бы способом вы не хотели заниматься что. Обычно вы копируете файлы script в каталог temp, загружаете их в архив, обрабатываете их и распаковываете. После этого вы, как правило, выполняете дополнительную работу на сервере, чтобы перемещать файлы, изменять символические ссылки, что бы вы ни делали.

Что относительно скомпилированных файлов SASS, ES6 js или современных статических материалов?

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

Когда вы настроили свой компилятор SASS и любой другой предварительно скомпилированный статический код, который у вас есть, вы настроили его для создания целевого файла. То есть, файлы фактического CSS и JS, которые они генерируют. Это все, что вам нужно взять с собой - и если у вас есть целевой каталог, установленный внутри вашей темы Wordpress, вам, возможно, даже не придется уделять этому особому особому обращению. Возможно, вам придется перемещать их где-то еще, как только они находятся на сервере, но все зависит от конкретной установки на вашем сервере, что, я думаю, выходит за рамки этого вопроса.

Дополнительные примечания:

Вы не спрашивали об этом, но я подумал, что стоит упомянуть, что вы не должны отправлять весь репозиторий Wordpress каждый раз, когда вы обновляете. Так же, как вам не нужен несвязанный код SASS, вам также не нужно переупаковывать основной WordPress. Вам даже не нужно выполнять основной WordPress, его зависимость, и вам не нужно его менять.

Все, что должно быть совершено вами, - это ваша тема и код плагина, а также нескомпилированные статические файлы. Скомпилированные статические файлы и внешние зависимости, такие как ядро ​​WordPress, не относятся к вашей истории git. Для развертывания WordPress уже должен быть установлен. Материалы в ваших архивах должны быть просто плагинами и темами, а также дополнительными статическими файлами, если они по какой-то причине еще не присутствуют.

TL;DR;

Не используйте git для этого. Используйте такой инструмент, как Phing или Deployer. Создайте свои статические файлы в своей теме и создайте сценарии phing/deployer, которые загружают только тот код, который вы хотите, SSH на свой сервер и разворачиваете его в нужные вам каталоги. Если у вас есть определенное место на сервере для ваших статических файлов, просто убедитесь, что для этого добавлены шаги в script.

Ответ 3

Итак, основываясь на вашем вопросе и комментарии, задействованы три компьютера. Существует веб-сервер (когда вы говорите "сервер", я воспринимаю его как веб-сервер в этом сценарии или серверный компьютер, на котором запущена программа веб-сервера). Существует еще один сервер, на котором размещается ваш репозиторий git. И есть ваша рабочая станция dev. Правильно ли это?

Похоже, у вас есть клонированный репозиторий git на вашем веб-сервере. Ваша текущая практика/рабочий процесс выглядит как (1) (на основе вашего выражения "SSH'ed на мой сервер" ), вы регистрируетесь на веб-сервере через SSH (точно так же, как Telnet) с вашей рабочей станции (SSH - это всего лишь протокол, который может использоваться для разных целей). (2) вы вытаскиваете из своего репо на размещенную службу (например, github) и (3) развертываете ее в своем каталоге "www" на том же сервере. Правильно ли это?

(Я могу подумать об альтернативном сценарии, основанном на использовании слова "FTP" и т.д., но теперь сосредоточьтесь на вышеупомянутом сценарии.)

Теперь, ваш вопрос заключается в том, что всякий раз, когда вы "тянете" (на своем веб-сервере), вы чувствуете, что вы тянете все от своего репо на своем размещенном сервисе. И есть ли лучший способ? Правильно ли я понимаю ваш вопрос?

Если это так, как предложил другой комментатор, git (и любая система управления версиями в целом) очень хороша при выборе "дельта". Если вы беспокоитесь о том, что каждый раз, когда вы тянете ( "шаг" (2)), вы беспокоитесь, то ваше беспокойство необоснованно.

Теперь возникает вопрос: почему у вас есть репозиторий git на вашем веб-сервере, если это действительно так? Это довольно законная настройка, и я сделал это раньше (например, на EC2). Но, как лучшая практика, люди обычно не делают этого на "производственных" серверах. Это потому, что вам нужно "создать" ваше веб-приложение, и вы действительно не хотите делать это на производственных серверах.

Следующий вопрос: что именно вы делаете на шаге (3)? Процесс сборки (независимо от используемого процесса) обычно генерирует "вывод", который может быть непосредственно развернут на веб-сервере. (Соглашение - это, как правило, одна папка "public", "www", "dist" или что-то еще, или один файл (например, tar.gz, zip, jar, war) и т.д.) Независимо от того, независимо от того, строите ли вы разворачиваемый вывод на своей рабочей станции dev (или на машине сборки) или на вашем веб-сервере, вы обычно не делаете "дельта" в этом контексте. Даже если вы только изменили один файл (скажем, файл CSS), вы, как правило, снова создаете весь вывод (вместо, скажем, просто заменяете только измененный файл CSS). Когда вы используете FTP для загрузки файлов и т.д., Вы можете выборочно загружать определенные файлы и/или каталоги и т.д., Но в качестве общей практики мы этого не делаем. Мы всегда строим полный результат с нуля и развертываем его на веб-сервере. (Это в основном для уменьшения потенциальных ошибок развертывания и повышения надежности.)

Итак, чтобы ответить на ваш вопрос, (A) Если вы нажимаете git repo на своем веб-сервере, вы должны действительно изменить эту практику и переместить процесс сборки на ваш компьютер-разработчик или на специализированную машину сборки. (BTW, такие сервисы, как github, gitlab, TFS,... предоставляют вам услугу сборки.) (B) Если вы в настоящее время выборочно FTP'ите свои файлы веб-приложений на свой веб-сервер, то вам действительно стоит подумать о принятии какого-либо вида формальной сборки и развертывания, продвигается вперед.

Ответ 4

После завершения процесса сборки SASS используйте scp или rsync, чтобы переместить файлы на сервер prod:

scp -r /[local wordpress dir]/wp-content/themes/your-theme/ [email protected]:/path/to/dir/wordpress/wp-content/themes/

scp -r /[local wordpress dir]/wp-content/plugins/* [email protected]:/path/to/dir/wordpress/wp-content/plugins/

Ответ 5

I am working in a project and using git ssh with bitbucket following is the process i am using it may work for you also if not please correct me :

Step 1 ->I have setup git and create repo in bit-bucket.
Step 2 ->And setup project with my local and linked with my repo.
Step 3 ->connect my server using ssh.
Step 4 ->Work in my local and commit and push all changes in my git repo.
Step 5 ->Run git pull on ssh so all changes deployed in my server.

I am using above process and i love this process.i have used .gitignore  file that is not required for push on my repo.

Thanks