Все файлы блоговского движка я храню в Git. Я не стану всем и каждому советовать сразу переходить на систему контроля версий. Очевидно, что для её развертывания потребуется как минимум VPS, навыки администрирования и, собственно, умение пользоваться ею. Иначе все плюсы обратятся в сплошные минусы.

Однако, преодолев все эти трудности можно получить некоторые преимущества.

Редактирование темы и плагинов

Благодаря Git редактировать файлы можно как на домашнем компьютере, так и прямо на сервере. При этом точно знаю, что ничего не «случайно» не потеряется или перезатрется.

Если один и тот же файл был изменен в разных местах, то система сама попробует решить конфликт. А если её это окажется не под силу, то предоставит вам эту возможность.

Обновление версии движка

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

Чтобы сохранить свои исправления я выработал такую схему работы

В одной ветке (wp31) я храню исходные файлы дистрибутива и все новые версии разворачиваю только туда. А свои правки делаю в основной ветке (master).

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

Развертывание изменений на сервере

Все действия сводятся к одной простой команде.

git pull

Если вдруг обнаруживаются какие-то дефекты, то старая версия блога возвращается на прежнее место за несколько секунд.

Резервное копирование

Каждый Git-репозиторий может стать резервной копией для других. Фактически у меня 3 идентичных копии: продакшин, внешний репозиторий и локальный репозиторий на домашнем компьютере. В случае повреждения одной из них, восстановить её можно будет из двух других копий.

54307730.19286420.1324395758.c7d8ac3d6d9658c7c572ebaca98a9ceb

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

Создание тега

1. Помечаем локальный коммит

   git tag 12345
   

2. Отправляем его во внешний репозиторий

   git push origin 12345
   

Удаление тега из репозитория

1. Удаляем тег локально

   git tag -d 12345
   

2. Удаляем его во внешнем репозитории

   git push origin :refs/tags/12345
   

3. Оповещаем каким-либо способом коллег, чтобы они сделали у себя команду из пункта 1

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

Перемещение тега на другой коммит

1. Принудительно перезаписываем тег

   git tag -f 12345
   

2. Отправляем во внешний репозиторий с принудительной перезаписью

   git push --force origin 12345
   

3. Оповещаем коллег как и в случае удаления тега

Дополнение

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

git tag 12345 6ff87c4664981e4397625791c8ea3bbb5f2279a3

Отправить во внешний репозиторий все теги текущей ветки можно одной командой.

git push --tags

После того, как gitosis установлен и настроен доступ к нему из вне, можно переходить к созданию отдельных хранилищ проектов.

Для конфигурирования gitosis используется инфраструктура git. При инициализации нового репозитория всегда создается проект gitosis-admin, где хранятся файлы конфигураций и ключи доступа. Как только в этот проект делается комит с изменениями настроек они сразу же применяются. Это обеспечивается скриптом post-update. Нужно убедиться, что он может выполняться.

sudo chmod 755 /Users/git/repositories/gitosis-admin.git/hooks/post-update

Сделаем копию этого проекта на рабочем компьютере

git clone git@repo.local:gitosis-admin.git

В файле gitosis.conf содержится описание проектов и прав доступа к ним, а в директории keydir — публичные ключи других пользователей репозитория.

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

git commit -a -m "Комментарий к комиту"
git push

Создание нового проекта

Исходная конфигурация в gitosis.conf

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = user1

В строке members перечисляются имена ключей (без расширения .pub), которые лежат в папке keydir.

По аналогии добавим еще одну группу:

[group project1]
writable = project1
members = user1

Эти правила задают группу project1, в которую входит пока только 1 пользователь user1. Все пользователи из этой группы имеют доступ для записи в проект project1.

Сохраним изменения и опубликуем их в удаленный репозиторий.

Теперь создадим сам проект. На рабочем компьютере выполним команды:

mkdir project1
cd project1
git init
git remote add origin git@repo.local:project1.git

Было бы хорошо, если к этому моменту у вас уже были какие-либо файлы, которые можно отправить в репозиторий. Если таковых нет, то нужно создать пусть даже пустой файл, чтобы его опубликовать (потом этот файл можно удалить или отредактировать).

touch file.txt

Отправляем проект в удаленный репозиторий:

git add .
git commit -a -m 'init commit'
git push origin master:refs/heads/master

Проект с названием project1 будет создан на сервере в директории /Users/git/repositories/

Переустановка системы на домашнем сервере подтолкнула написать еще одну подробную инструкцию по настройке git-репозитория на Mac OS X 10.6 (Snow Leopard)

Установка и настройка gitosis

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

cd ~/Desktop
mkdir src
git clone git://eagain.net/gitosis.git
cd gitosis
sudo python setup.py install

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

Найдем не используемые uid и gui

sudo dscl . list /Users uid
sudo dscl . list groups gid

Предположим, что число 410 не используется в обоих случаях. Это будет нашим идентификатором.

Создаем группу git

sudo dscl . create groups/git
sudo dscl . create groups/git gid 410

Создаем пользователя git

sudo dscl . create users/git
sudo dscl . create users/git uid 410
sudo dscl . create users/git NFSHomeDirectory /Users/git
sudo dscl . create users/git gid 410
sudo dscl . create users/git UserShell /bin/bash
sudo dscl . create users/git Password '*'

Создаем домашнюю директорию пользователя

sudo mkdir /Users/git
sudo chown git /Users/git
sudo chgrp git /Users/git

Теперь для текущего пользователя на локальном компьютере сгенерируем ssh ключ, если его еще нет. Если ключ есть, то этот шаг пропускаем

ssh-keygen -t rsa

И копируем его на удаленный сервер

scp ~/.ssh/id_rsa.pub repo.local:/tmp/my_key.pub

Если же репозиторий создается на рабочем компьютере, то эта команда немного упрощается

cp ~/.ssh/id_rsa.pub /tmp/my_key.pub

Теперь на сервере выполним инициализацию репозитория

cd /Users/git
sudo -H -u git gitosis-init < /tmp/my_key.pub

При удачном раскладе вы должны увидеть сообщения вроде этих

Initialized empty Git repository in /Users/git/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /Users/git/repositories/gitosis-admin.git/

Устанавливаем переменную PATH для пользователя git

sudo su git
echo "export PATH=$PATH" > ~/.bashrc
exit

На этом настройку gitosis можно считать законченной. Проверим подключение к репозиторию из вне.

git clone git@repo.local:gitosis-admin.git

Если вы увидите сообщение

Cloning into gitosis-admin...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 5 (delta 0)
Receiving objects: 100% (5/5), done.

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

Потенциальные проблемы

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

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