Для каждого фиксации создайте эквивалентное скомпилированное коммитирование в отдельном репо или ветки

Ответ 1

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

Правильное ключевое слово для вас - "Непрерывная интеграция".

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

The Build Script, который вы настраиваете в CI Software, не отвечает за развертывание артефактов сборки, в этом случае вашу скомпилированную версию, в вашу целевую систему, такую ​​как ведро s3. Вы также можете выполнить программную фиксацию своих артефактов в другом репо git.

Посмотрите здесь: https://jenkins.io/doc/

Ответ 2

Ваше решение будет смешиваться в одном и том же репо "источник коммитов" и "доставка коммит" (_site скомпилированная версия), что не является лучшей практикой (и будет увеличивать размер репозитория Git бесполезно)

Я бы создал отдельный репо "site", который я бы добавил как submodule к вашему текущему репо, по пути _site/.

cd /path/to/current/repo
git rm -R _site
git submodule add -- /url/repo/site _site

Таким образом, каждый раз, когда вы создаете свою поставку с помощью пакета exec jekyll build, это делается в отдельном репо (в _site), где вы можете добавлять, фиксировать и даже прямо нажимать туда, где вы хотите его протестировать.
Затем вы возвращаетесь к основному репо, где вы добавляете и фиксируете специальную запись gitlink (в индексе), установив прочную связь между точной версией источника и точной версией доставки (встроенный сайт).

Ответ 3

Как вы просили

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

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

Я предлагаю вам выбрать ветку для "производственного" состояния кода. И когда вы начинаете в этом ветке - код должен быть перестроен. Назовите его "производство".

• Сделайте отдельный репозиторий git для встроенного кода.
• Поместите этот код в post-commit hook в репозиторий src. Он будет обрабатывать все фиксации в производственной ветки, проверять код во временном каталоге, делать сборку и фиксировать изменения.

srcDir='../srcWorkTree'
buildedRepo='../buildedRepo'

if [ `git rev-parse --abbrev-ref HEAD` == "production" ]; then
    echo "making builded code commit..."
    mkdir -p $srcDir
    # http://stackoverflow.com/questions/4479960/git-checkout-to-a-specific-folder
    git checkout-index -a -f --prefix=$srcDir/

    bundle exec jekyll build --source $srcDir --destination $buildedRepo

    cd $buildedRepo
    git add -A
    commitInfo=$( git log -1 --pretty="%h %B" )
    git commit -m "autobuild for $commitInfo"
    # git push
fi

Другой вариант

Как я могу предположить, у вас есть доступ к вашему серверу. По крайней мере, вы упомянули, что у вас есть git repo. Поэтому будет разумно сделать там пост-прием, чтобы создать код в целевой каталог. Это будет более понятно и просто, вместо того, чтобы делать это на локальном компьютере, как я описал.

Я полагаю, что это репо "голая", потому что у вас не должно быть возможности вносить изменения на сервере.

post-receive hook:

#!/bin/sh

siteDir='/var/www/site'
tmpSrcDir='/var/www/site'

echo "**** [builder post-receive hook]"

while read oldrev newrev refname
do
    if [ $refname = refs/heads/production ]
    then
        GIT_WORK_TREE=$tmpSrcDir git checkout --detach $newrev

        bundle exec jekyll build --source $tmpSrcDir --destination $siteDir
    fi
done

exit 0

И несколько комментариев

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

Ответ 4

Я просто предлагаю другой вариант: не хранить скомпилированные версии в git, хранить их где-то еще.

Чтобы дать вам наш рабочий процесс в качестве примера:

• когда нам нужно протестировать конкретный коммит, мы запускаем его через наш процесс CI, который создает архив .tar.gz, и мы используем наш инструмент развертывания для проверки его на промежуточном сервере;

• когда мы выбираем фиксацию для версии выпуска, мы отмечаем это commit в git, мы запускаем его через CI-процесс,.tar.gz помечен номером версии и сохраняется в некотором releases/ на нашем сервере развертывания.

У нас есть резервная копия нашей папки releases/, но если мы ее потеряем, мы также можем перестроить любую конкретную сборку из исходного кода (на основе тега).

Ответ 5

Инициализируйте репозиторий Git в _site/, затем добавьте Git post-commit hook, .git/hooks/post-commit:

echo -n "Add commit to compiled version? (y/N) "
read answer < /dev/tty
if [ "$answer" != "y" ]; then exit; fi

message=$( git log -1 --pretty=%B )

git stash --all
bundle exec jekyll build

cd _site
    git add --all
    git commit -m "$message"
cd ..

git stash pop

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