Размещаем Jekyll с расширениями на GitHub, оттачивая своё Git-фу

19 сент. 2012

Изначально GitHub подкупает тем, что предлагает готовую среду для статического сайта с Jekyll и средствами обслуживания Git. Позже вскрывается и его теневая сторона: на GitHub Pages доступен только «стерильный» Jekyll без расширений, тогда как их количество растёт день ото дня. Если вы вкусили сладость сторонних расширений (например, на локальной системе) и остались довольны, то почему бы не использовать их дальше, а на GitHub отсылать готовые HTML-страницы? Освоив начала Git-фу, вы сможете управлять по-отдельности и исходниками (для личного удобства), и готовым результатом (для размещения на сайте).

Генерация сайта локально

Давайте исходить из того, что у вас есть сайт на GitHub Pages, исходники которого хранятся в ветке master репозитория username.github.com. При переходе на локальную генерацию сайта желательно иметь следующие возможности:

  • Отдельно представлять изменения в исходниках сайта без учёта директории _site/.
  • Содержимое директории _site/ должно попадать в корень ветки master репозитория на GitHub.

Вы можете воспользоваться топорным методом или более изящными решениями, доступными после ознакомления с подмодулями Git. Решения, использующие подмодули, на просторах интернета доступны тут и там. Идея в том, чтобы хранить исходники сайта в отдельной ветке source с директорией _site/ как подмодулем, который в свою очередь передаётся напрямую в master. Предлагаю вашему вниманию творческую переработку этих решений с замечаниями, найденными в процессе освоения.

Примечание. Настоящие джигиты, вероятно, предпочтут git subtree, уже вошедший в состав Git с версии 1.7.11.

Создание ветки с исходниками

Внимание! Перед внесением изменений обязательно создайте резервную копию вашего репозитория.

Переименуем локально ветку master в source:

$ git branch -m master source

Выполним push ветки с исходниками в удалённый репозиторий origin, попутно создав там ветку source

$ git push -u origin source

Теперь у нас есть локальная ветка source и две удалённые: master и source. Опция -u (или --set-upstream) указана неспроста: без неё локальная ветка следовала бы origin/master, как это было до переименования. Другими словами, git pull забирало бы изменения не из свежесозданной origin/source, а как и прежде — из origin/master (такое странное поведение объясняется несимметричностью push в Git). Опция -u призвана устранить подобное несоответствие.

Подключение подмодуля

Удалите директорию _site/ и уберите из .gitignore: после добавления _site/ как подмодуля, содержимое данной директории не будет смешиваться с исходниками, как и прежде, когда находилось в .gitignore. Добавим удалённую ветку master уже на правах подмодуля

$ git submodule add -b master <repository> _site

Вместо <repository> следует подставить ссылку вида git@github.com:username/username.github.com.git на удалённый репозиторий.

Теперь в корне Git-директории находится ветка source, а в _site/ — ветка master, в точности соответствующая удалённой origin/master. В данных ветках правки можно вносить, контролировать и отсылать на GitHub независимо друг от друга.

Тонкости работы Jekyll

Как и прежде, запуск Jekyll изменяет содержимое директории _site/, представляющей собой ветку master. При этом файл .git, необходимый Git для работы с _site/ как подмодулем, остаётся на месте, если версия Jekyll не меньше 1.0. Дадим понять GitHub Pages, что запускать Jekyll не надо при помощи пустого файла .nojekyll. Начиная с Jekyll 0.12, скрытые файлы учитываются наравне с другими, если их явно указать в _config.yml

include: ['.nojekyll']

Соответствующий файл-пустышка .nojekyll должен находиться в директории с исходниками.

Наверх

Наверх