Как поднять блог на Github Pages. Хостинг гитхаб

Git - Book

2nd Edition (2014)

Switch to 1st Edition

Download Ebook

The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com.>

1. 1.1 О системе контроля версий
2. 1.2 Краткая история Git
3. 1.3 Основы Git
4. 1.4 Командная строка
5. 1.5 Установка Git
6. 1.6 Первоначальная настройка Git
7. 1.7 Как получить помощь?
8. 1.8 Заключение
1. 2.1 Создание Git-репозитория
2. 2.2 Запись изменений в репозиторий
3. 2.3 Просмотр истории коммитов
4. 2.4 Операции отмены
5. 2.5 Работа с удалёнными репозиториями
6. 2.6 Работа с метками
7. 2.7 Псевдонимы в Git
8. 2.8 Заключение
1. 3.1 О ветвлении в двух словах
2. 3.2 Основы ветвления и слияния
3. 3.3 Управление ветками
4. 3.4 Работа с ветками
5. 3.5 Удалённые ветки
6. 3.6 Перебазирование
7. 3.7 Итоги
1. 4.1 Протоколы
2. 4.2 Установка Git на сервер
3. 4.3

git-scm.com

гитхаб хостинг

Home
Trends
LIVE

Home
Trends
Live TV

Как развернуть Git на хостинге / СоХабр

Гит — это ок. В 2016-м году файлики через FTP никто не таскает. Почти все знакомы с базовыми командами, но не каждый умеет настраивать git на хостинге (о облачных выделенных серверах я вообще молчу). Поэтому я решил выложить для всех свою шпаргалку о разворачивании гита на хостинге. В моем случае — это Бегет, но у других хостеров примерно так же.

Шаг 1

Создаем FTP-юзера с доступом к корневой директории сайта (на уровень ниже от public_html) и включаем для него SSH. Сразу же запишем куда-нибудь доступы. Мы храним их в таком формате:Логин FTP-юзера: username Пароль: ************ Репозиторий: username@server-ip:project.git

Шаг 2

В корневой сайте создаем папку. ssh, а в ней файл authorized_keys. Туда запишем ssh-ключи людей, которые будут работать с этим проектом. Можно это сделать через ФТП, но мне привычней через SSH.ssh username@server-ipmkdir .sshcd .sshtouch authorized_keysnano authorized_keys

О том как сгенерировать SSH-ключ есть отличная инструкция на Гитхабе.

Шаг 3

В папке public_html инициализируем новый репозиторий и добавим файлы под контроль версий.cd ~/public_htmlgit initgit add -Agit commit -m 'Init'

Шаг 4

Создаем новый репозиторий, который будет служить шлюзом для основногоcd ../git clone --bare public_html project.gitcd public_htmlgit remote add hub ../project.gitgit remote show hub

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

Шаг 5

В /public_html/.git/hooks/ создаем файл post-commit и ставим ему права 700. cd ~/public_html/.git/hookstouch post-commitchmod 700 post-commitnano post-commit

Внутрь помещаем следующее:

#!/bin/sh echo echo «Пушим изменения...» echo git push hub

Шаг 6

В /project.git/hooks/ создаем файл post-update и ставим ему права 700.cd ~/project.git/hookstouch post-updatechmod 700 post-updatenano post-update

Внутрь помещаем следующее:

#!/bin/sh echo echo «Вытягиваем изменения...» echo cd ~/public_html/ || exit unset GIT_DIR git pull hub maste exec git-update-server-info

Успех!

Это все, после этого можно клонировать репозиторий и работать:git clone username@server-ip:project.git

sohabr.net

Git и публикация сайта / Хабр

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

Я потратил несколько месяцев на борьбу с глюками Git-svn и обдумывание разных вариантов, прежде чем пришёл к этому методу организации рабочего процесса с сайтом — простому, гибкому и удобному в работе.

Основные преимущества:

Делая push из удалённой копии мы автоматически обновляем live-копию сайта

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

Обзор

Главная идея системы — создение на сервере двух репозиториев: пустого bare-репозитория и обычного репозитория с рабочей копией сайта. Эта пара связана парой простых хуков, которые автоматизируют push и pull изменений.

Итак, два репозитория:

Hub — bare-репозиторий. Все репозитории разработчиков клонируются именно от него.
Prime — обычный репозиторий. Сайт запускается из рабочего каталога этого репозитория.

Работа с двумя репозиториями простая и очень гибкая. Удалённые копии, имеющие ssh-доступ могут легко обновлять live-версию сайта просто выполнив push в Hub-репозиторий. Любые изменения, выполненные в live-версии на сервере мгновенно вливаются в Hub при коммите. В общем, всё работает очень просто — и неважно, где делаются изменения.

Небольшие приготовления перед стартом

Естественно, в первую очередь нужно, что бы Git был установлен на сервере и на всех компах разработчиков. Если на вашем shared-хостинге не установлен Git — вы очень легко можете это исправить (en).

Если вы первый раз работаете с Git на своём сервере, не забудьте указать глобальные настройки. Я указываю особое значения для user.name, чтобы потом видеть в истории проекта изменения, выполненные на сервере:

$ git config --global user.name "Джо, фигачу на сервере"

Поехали!

В первую очередь создадим новый git-репозиторий в live-каталоге нашего сайта, а затем добавим и зафиксируем все файлы сайта. Это будет Prime-репозиторий и рабочая копия. Даже если уже есть история проекта в других местах, содержимое сайта будет базовой точкой, в которую потом будут слиты все остальные копии.$ cd ~/www $ git init $ git add . $ git commit -m "Импорт всех существующих файлов сайта" Поскольку мы сделали инициализацию репозитория в рабочей копии – нет нужды отключать сайт на обслуживание и повторно выкладывать все файлы, Git просто содаст репозиторий из имеющихся файлов.

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

$ cd $ mkdir site_hub.git $ cd site_hub.git $ git --bare init Initialized empty Git repository in /home/joe/site_hub.git Ура! Снова вернёмся в рабочий каталог сайта и добавим Hub как удалённый репозиторий, а затем вольём в Hub содержимое ветки master из Prime-репозитория.$ cd ~/www $ git remote add hub ~/site_hub.git $ git remote show hub * remote hub URL: /home/joe/site_hub.git $ git push hub master

Хуки

Как я уже упоминал в начале, Hub и Prime синхронизируются между собой, используя два простых скрипта.

Одно из основных правил при работе с Git — никогда не делайте push в репозтирий, у которого есть рабочая копия. Мы следуем этому правилу и создали репозиторий «Hub». Вместо того, чтобы делать push из Hub, который никак не повлияет на рабочую копию, мы будем использовать хук, который заставит Prime выполнить pull из Hub-репозитория.

Post-update — в Hub-репозитории

Как только в Hub поступит новая порция изменений, сразу будет выполнен этот скрипт. Мы переходим в рабочий каталог Prime-репозитория, и вытягиваем измениния из Hub'а. Проталкивание изменений (push) не изменяет состояния рабочего каталога репозитория, поэтому и нужно делать pull, находясь в рабочем каталоге.#!/bin/sh

echo echo "**** Вытягиваем изменения в Prime [Hub's post-update hook]" echo

cd $HOME/www || exit unset GIT_DIR git pull hub master

exec git update-server-info

Post-commit — в Prime-репозитори

Этот скрипт запускается после каждого коммита в Prime-репозитории и проталкивает изменения в Hub. В идеальном мире, конечно, мы вообще никогда ничего не будем править прямо на сервере. Но в нашем несовершенном мире возможно всё, что угодно, поэтому давайте автоматизируем процесс проталкивания изменений, чтобы не разрушать историю проекта и избежать возможных конфликтов.#!/bin/sh

echo echo "**** pushing changes to Hub [Prime's post-commit hook]" echo

git push hub

Итак, используя этот хук, мы сразу же получаем в Hub-репозитория все изменения, выполненные в master-ветке Prime-резпозитория. Прочие ветки также можно клонировать, но они не будут влиять на сайт. Поскольку все удалённые копии получают доступ через SSH-адрес к Hub, то выполнить push и запустить обновление сайта напрямую могут только пользователи, имеющие прямой доступ к shell'у.

Конфликты

«Положить» сайт при такой системе синхронизации двух репозиториев очень сложно. Каждое изменение, сделанное в Prime автоматически попадает в Hub и все конфликты будут сразу видны при попытке выполнить push из клонов репозитория.

Но всё же есть несколько ситуаций, при которых состояние Prime может отличаться от Hub'а, и для исправления ситуации потребуется выполнить несколько дополнительных телодвижений. Если мы что-то правим на Prime и не зафиксировали изменения, а в этот момент сработает post-update в Hub, то все завершится ошибкой с сообщением «Entry ‘foo’ not uptodate. Cannot merge.». Фиксация изменений в рабочем каталоге Prime позволит зачистить его состояние, и post-update хук сможет соединить все неотправленные изменения.

Также я обнаружил, что если конфликт возникает вследствие того, что изменения в Prime не могут быть объединены с Hub'ом, то наилучшим решением будет протолкнуть текущее состояние Prime'а в новую ветку на Hub. Эта команда, выполненная из рабочего каталога Prime создаст удалённую ветку «fixme», основанную на текущем стоянии Prime-репозитория.

$ git push hub master:refs/heads/fixme Как только изменения окажутся в Hub'е, мы сможем получить ветку в любом из клонов, разрешить конфликт и смержить ветки. Попытка разрешить конфликт прямо на сервере почти наверняка приведёт к проблемам в работе сайте из-за появления маркеров конфликтных областей.

Держим всё в чистоте

Каталог .git Prime-репозитория находится в корневом каталоге сайта, и, верояно, доступен для публичного доступа. Чтобы никто не смог сунуть свой нос, куда не следует, добавьте эти строки в файл .htaccess верхнего уровня:# deny access to the top-level git repository: RewriteEngine On RewriteRule \.git - [F,L]Прим. переводчика: есть и другие способы закрыть доступ к каталогу на сервере.

Прочие проблемы

Если при попытке выполнить push в репозиторий на сервере вы видите эту ошибку:git-receive-pack: command not found fatal: The remote end hung up unexpectedly В этом случае просто добавьте export PATH=${PATH}:~/bin в ваш файл .bashrc, лежащий на сервере.

habr.com

Как поднять блог на Github Pages · Записная книжка

04 Jan 2015

Первый пост блога, инструкция.

Содержание

Лирика

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

Останавливало два фактора: лень и незнание веб-технологий(и отсутсвие большого желания изучать их). Использовать же современные готовые движки типа Wordpress, Blogger или LiveJournal и иже с ними не хотелось из-за их перегруженности, “вебдванольности”, не подконтрольности мне. Да и большинство функционала, который предлагают современные блоги/дневники, мне не нужно.

И вот тут в очередной раз гуляя по Github я наталкиваюсь на Github Pages. Полчаса чтения и я понимаю — это то что нужно. Суть в чем? Сервис предлагает пользователям Github бесплатный хостинг статических html-страниц для специально созданного репозитория. Простые страницы все же не блог — так какой же от сервиса толк? Там есть генератор удобный, который из пачки шаблонов и простого текста сгенерирует сайт пользователю на радость командой одной — git push — прелесть какая.

Если коротко, то вот что меня привлекло завести блог на Github Pages:

отсутствие желания заниматься самому настройкой сервера, следить за обновлениями, безопасностью и все такое. На Github Pages это происходит без моего участия;
набор статических html-страниц, а значит быстро будет отображаться в браузере;
есть генератор этих самых статических страниц — Jekyll, а значит не надо будет самому заниматься версткой постов;
раз статические страницы, то не надо никаких баз данных, php и тому подобных вещей;
посты пишутся в простом markdown-формате, а значит подойдет тем кто не хочет вообще заморачиваться с html;
git; это значит многое: версионность, локальное хранение, безопасность(шифрованные данные же пересылаем ) и еще очень много хорошего;
возможность привязать к своему домену блог;
возможность кастомизации по самое не хочу … для тех кто хочет.

Установка и настройка окружения

Вместо чтения кучи документации по Jekyll, я нашел крутую репу poole. Как пишет ее автор:

“a clear and concise foundational setup for any Jekyll site. And it has a super minimal look… It does so by furnishing a full vanilla Jekyll install with example templates, pages, posts, and styles.”

Т.е. минимально необходимый набор для запуска блога: форкнул, поменял настройки под себя и пользуешься на здоровье. Правило “Все уже написано до нас!” работает безотказно :) .

demo.getpoole.com — рабочее демо блога:

The demo pool website

Приступим к созданию своего блога:

устанавливаем Ruby;
устанавливаем Ruby DevKit;
устанавливаем Jekyll. Я сначала установил генератор так: gem install jekyll. И это правильно в общем случае. Но не в случае с Github. Сайт использует не последнюю версию. И возможна такая ситуация, когда вы случайно задействуете новую фичу, которая не поддерживается той версией Jekyll, которая установлена на Github. Узнать текущую версию можно здесь. Установить требуемую версию Jekyll можно так: gem install jekyll -v x.y.z. Но гораздо проще воспользоваться готовым пакетом от самых ребят с Github: gem install github-pages, он разворачивает текущее окружение, используемое Github, у вас на компьютере;Update: с докером все намного проще:

docker run -ti --rm -v “$PWD”:/usr/src/app -p “4000:4000” starefossen/github-pages

клонируем репозиторий poole;
запускаем локально сайт, для этого в консоли переходим в папку с poole и вводим jekyll serve. После того как Jekyll запуститься, мы сможем узреть сайт по адресу http://localhost:4000. Когда вы запускаете Jekyll, он создает папку _site, в которую записывает сгенерированный блог. Каждый файл в репозитории будет скопирован внутрь папки, за исключением тех файлов/папок, которые начинаются с подчеркивания. Markdown-файлы будут автоматически конвертированы в соотв. страницы. В папке _posts должны находится посты в markdown-формате. При чем имя файла должно быть вида год-месяц-день-название_поста.md. Иначе для него не сгенерируется соответствующая html-страница. _config.yml — конфигурационный файл Jekyll, меняем его под свои надобности, подробно почитать о настройке здесь. Важное примечание: по умолчанию Jekyll при любом изменении файлов перезапишет сайт, но если вы поменяли что-то в _config.yml, то надо перезапустить Jekyll;
добавляем посты, меняем шаблоны и вообще делаем что желаем;
создаем на Github новый репозиторий с именем вида github_username.github.io;
заливаем/пушим в него наш блог;
спустя небольшое время(до получаса) блог становиться доступен по адресу http://github_username.github.io
если есть свой домен, то Github легко позволяет привязать его к блогу. Руководство от Github, больше инфы для тех у кого регистратор домена Namecheap.

Кастомизация

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

Дефолтная тема poole мне подошла практически идеально. Но захотелось изменить еще некоторые вещи.

Добавил три ссылки вверху:

О блоге
Архив записей - динамически формирующийся список записей, для быстрой навигации;
Лента - для желающих подписаться на обновления блога.

Для этого я добавил в _config.yml:

pages_list: О блоге: '/about' Архив записей: '/archive' Лента: '/atom.xml'

И модифицировал шаблон _layouts/default.html:

<h4> <a href="/" title="Home">{{ site.title }}</a> {% for page in site.pages_list %}     <small><a href="{{ page[1] }}">{{ page[0] }}</a></small> {% endfor %} <p> <small>{{ site.tagline }}</small> </p> </h4>

Еще оказалось что с нуля нет поддержки тегов, что есть не классно. Для Jekyll есть отдельный плагин, который реализует теги, но в нашем случае это не подходит, так как тот Jekyll, который крутится на серверах Github, нельзя кастомизировать плагинами. Памятуя о правиле “Все написано до нас”, я полез в Google и спустя 5-ть минут решение найдено. Расписывать много не хочется, решение полностью скопировано, для наглядности будет удобно посмотреть diff. А именно файлы poole.css, index.html, post.html и tags.html.

Честно говоря я ни грамма не понял, что я за магию сделал, для того что бы теги заработали(что взять с С++ разработчика?), но все получилось и работает так как мне нужно. Вот, что крест животворящий свободный софт делает!

Итоги

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

Ссылки

официальный сайт Jekyll с очень хорошей документацией;
документация Github Pages;
poole репозиторий.
руководство по markdown;
пост чувака, на который я ориентировался при настройке блога;
пост чувака для настройки мультилингвальности блога;
настройка DNS для Namecheap домена для блога на Github;
пост чувака, который рассказывает как добавить поддержку тегов без плагина Jekyll;
репозиторий моего блога.

alexprivalov.org

Создаем свой персональный сайт на Github. — klen.github.io

Mало кто знает, что Github кроме превосходного хостинга ваших Git проектов может также хостить ваш персональный сайт. Например на нем расположен этот блог. В своей первой статье я расскажу как максимально удобно настроить эту функциональность.

Для начала вам нужно быть зарегистрированным пользователем Github и уметь работать с системой контроля версий Git. Предположим вы готовы.

Первое, что вам потребуется — это создать на Github репозиторий с именем вида: username.github.com, где username ваш логин на сервисе. Например для этого блога создан репозиторий http://github.com/klen/klen.github.com
Вторым шагом мы создадим локальный репозиторий и привяжем его к удаленному:

Note

В дальнейшем я буду приводить примеры для своего сайта: klen.github.com

mkdir ~/Projects/klen.github.com cd ~/Projects/klen.github.com git init echo 'Hello world!' > index.html git add . git commit -m 'Initial commit' git remote add origin [email protected]:klen/klen.github.com.git git push -u origin master Отлично, ваш статический сайт уже готов! В течении 10 минут он появится по адресу: username.github.com. В дальнейшем он будет обновляться при коммитах в удаленный репозиторий.

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

Существует масса проектов генерации статических сайтов и блогов. При работе с ними фактически вы пишете страницы и статьи в удобном для вас формате, а затем генератор обновляет структуру сайта. По-умолчанию Github уже поддерживает написанный на ruby генератор Jekyll. То есть вам необязательно использовать только HTML синтаксис, из коробки вы можете писать в ваш сайт на Markdown. Подробнее читайте в документации Github Pages и Jekyll.

Я предпочитаю генерировать страницы локально и проверять результат без выгрузки содержания на Github. Мне привычнее работать с Python поэтому в качестве генератора сайта мной используется Pelican. Ниже я покажу как поставить его и настроить для работы.

Если вы предпочитаете ruby дальше можете не читать.

Предполагается, что вы знакомы с Python и VirtualEnv.

Так как мы будем использовать Pelican нам необходимо выключить встроенный в Github генератор Jekyll. Это делается добавлением в корень репозитория файла .nojekyll.

touch .nojekyll git add . git commit -m 'Disable Jekyll'

Теперь создадим и активируем виртуальное окружение для модулей нашего сайта:

virtualenv .ve_blog source .ve_blog/bin/activate

Установим в созданный нами VirtualEnv генератор Pelican и необходимый для него движок шаблонов Jinja2:

easy_install pelican easy_install jinja2

Мы будем держать исходники сайта в поддиректории source, а созданные статические страницы в корне репозитория, чтобы Github их видел. Создадим файл source/hello.rst с нашей первой статьей:

Hello world! ############ :slug: hello Hello from Pelican!

Note

Я использую синтаксис RST, но вы можете использовать Markdown для своего сайта. Просто сохраняйте файлы с расширением *.md Pelican поддерживает и другие форматы, но надо ставить соответствующие модули.

И соберем статику:

Note

Опция -o . заставляет Pelican производить сборку статики в корне проекта.

Если все прошло успешно в корне проекта вы увидите несколько HTML файлов. Откройте index.html в браузере и посмотрите на ваш сайт.

Теперь наши изменения можно сохранить в Git и отправить на Github.

git add . git commit -m 'Add virtualenv and setup pelican.' git push origin master

Настроим наш сайт и немного автоматизируем рутинные операции.

Создадим файл настроек нашего сайта source/settings.py:

AUTHOR = 'Kirill Klenov' SITENAME = 'klen.github.com' SITEURL = 'http://klen.github.com'

Note

Подробнее про настройки Pelican, можно прочитать в его документации.

Для упрощения сборки создадим sh-файл .compile

#!/bin/sh PRJ_DIR=/home/klen/Projects/klen.github.com VE_DIR=$PRJ_DIR/.ve_blog # Modify path OLD_PATH=$PATH PATH="$VE_DIR/bin:$PRJ_DIR:$PATH" export PATH # Compile static files pelican $PRJ_DIR/source -o $PRJ_DIR -s $PRJ_DIR/source/settings.py -v # Return PATH PATH=$OLD_PATH export PATH

И дадим ему права на исполнение:

Теперь в директории проекта можно вызывать ./.compile и собирать статику даже без активации виртуального окружения.

Следующим шагом создадим Git хук для автоматической генерации сайта при коммитах. Создадим и отредактируем файл .git/hooks/pre-commit:

#!/bin/sh PRJ_DIR=/home/klen/Projects/klen.github.com $PRJ_DIR/.compile

Note

Не забудьте сделать его исполнемым.

При каждом коммите изменений в репозиторий, проект будет пере-собран автоматически.

На этом нашу предварительную работу по созданию github-сайта можно считать оконченной. В дальнейшем стоит поподробнее прочитать документацию Pelican, модифицировать стандартную или создать собственную тему оформления и подключить какой нибудь сервис комментариев.

klen.github.io

Блог на Jekyll и Github / Хабр

Блог на Jekyll и Github

Для ведения блога существует множества прекрасных решений: posterous, blogger, wp… Выбирать можно и выбирать нужно, если вы хотите вести свой блог конечно. Сейчас я расскажу об относительно новом гик-решении в блоговедении — это Jekyll блог на базе Github. Jekyll — это простой генератор статичных сайтов, аля блог. Он содержит шаблоны для создания логики сайта. Благодаря Github Pages — сайт можно хостить на Github. Это просто. Создаете репозиторий «Название сайта».github.com и публикуете туда код вашего сайта на Jekyll. Commit+Push и Github автоматически обновляет ваш сайт.

Почему Jekyll + Github:

Jekyll предоставляет подсветку синтаксиса pygments, довольно неплохая.
Ваш блог хранится в git репозитории, а значит у вас есть версионное хранилище.
Jekyll компилирует сайт однажды и затем используются только статические html файлы.
Добавить изменения или написать новый пост значит сделать коммит на Github.
Популярность – посмотрите сколько watchers и forks у Jekyll github.com/mojombo/jekyll
Документация и примеры – работающие сайты и блоги в open source.
Удобный язык разметки. Jekyll поддерживает textile и markdown. Конечно html.
Надёжный хостинг.
Комментарии в блоге можно реализовать с помощью сервисов аля Disqus.

Инструкции по применению:

Пример блога на Jekyll с исходными кодами: исходники / сам сайт.

Пройдемся по исходникам:

_includes/ (готовые куски html для вставки) _layouts/ (шаблоны) _posts/ (статьи)

Шаблоны работают с помощью Liquid. Названия для постов требует строго форматирования аля год–месяц–день–name.format Формат: textile или markdown.

Пост должен включать шапку, обозначающую шаблон:

--- layout: post title: "Название поста" ---Достоинства:

1) Github. 2) Работает очень очень быстро — >95 из 100 очков профилируя через Google PageSpeed. 3) Можно легко переместить на Heroku.(к примеру) 4) Можно фокусироваться на контенте и не беспокоимся о реализации и платформе.

Недостатки:

1) Не так просто добавить: галерею фотографий, комменты, таги, поиск и тд. 2) Чтобы скрыть исходники вашего сайта нужен платный аккаунт, а это чуть более чем 7 долларов. (поправил) 3) Нету базы данных.

Заключение

Мне нравится Jekyll и GitHub, как хостинг. Это позволяет мне сфокусироваться на том, что я пишу, а не на технических проблемах. + на jekyll+github: мой блог.

habr.com