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

Gitolite позволяет управлять репозиториями, настраивать доступ, в общем практически все что нужно и даже чуточку больше. Подробнее об этом можно глянуть в википедии. Но если в кратце, то gitolite предоставляет доступ к репозиториям посредством ssh, авторизуя пользователей по ключам. С помощью коммитов в специальный репозиторий мы управляем остальными репозиториями. В общем до жути удобно, и максимально просто.

Установка Gitolite

Это очень просто. Для начала создадим специального юзера в системе (допустим server_git), а после от его имени выполняем:
cd ~
git clone git://github.com/sitaramc/gitolite
mkdir -p bin
gitolite/install -to ./bin

После вам нужно закинуть на сервер ваш публичный ssh ключ. Закиньте его в тот же каталог (key.pub), и выполняйте:
./bin/gitolite setup -pk key.pub
Это и все, gitolite установлен. По умолчанию будет создано два репозитория, gitolite-admin.git и testing.git. Первый, как вы уже понимаете — нужен для управления репозиториями. Он будет доступен по адресу:
ssh://server_git@server.com/gitolite-admin.git
(естественно для авторизации нужен приватный пара-ключ для key.pub с которым вы устанавливали gitolite одним шагом назад)

Администрирование Gitolite

Все в принципе очень просто. Клонируем к себе ssh://server_git@server.com/gitolite-admin.git и с помощью коммитов в этот репозиторий управляем доступом/созданием любых репозиториев. Для того чтобы добавить пользователя добавляем в каталог keydir/ публичный ключ этого пользователя. Создание нового репозитория еще проще. Редактируем файл conf/gitolite.conf. Добавляем репозиторий вот так:

repo newrepo
    RW+     =   user_first
    RW+     =   user_second

При этом в папке keydir/ должны быть ключи user_first.pub и user_second.pub соответствующих пользователей. Коммитим это все и пушим в репозиторий. После этого на сервере будет создан репозиторий newrepo, к которому будут иметь доступ соответствующие пользователи.

Автодеплой

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

Вкратце — система построена на хуках, и подтягивания изменений из основного репозитория в репозиторий dev версии. Вобщем глянем на схему:

Всей музыкой руководит приложение (назовем его AutoDeployApp), которое клонирует новый репозиторий если его еще нет (git init и git clone), или подтягивает изменения в существующий (git fetch и git reset) репозиторий Dev версии проекта.

AutoDeployApp

В моем случае это набор простых скриптов (скачать appDeploy). Распаковываем в ~/projects/. Открываем ~/projects/config.php и правим, в моем случае конфиг выглядит вот так:

define('CONFIG_BASEPATH', '/var/www/server_git/data/');
define('CONFIG_DEFAULT_REPOSITORIES', CONFIG_BASEPATH . 'repositories/'); //gitolite repos
define('CONFIG_DEFAULT_CONTENTS', CONFIG_BASEPATH . 'www/git.intsystem.org/'); //path to live versions

define('CONFIG_REMOTE_REPO', 'ssh://server_git@server-git-local/');

Где ssh://server_git@server-git-local/ адрес сервера с gitolite. Т.к. хук обновляет репозиторий через SSH, осуществляя подключение к самому себе же, я просто создал алиас server-git-local в ~/.ssh/config в таком виде:

Host server-git-local
  HostName git.intsystem.org
  User server_git
  StrictHostKeyChecking no
  IdentityFile ~/.ssh/server_git

При этом нужно сгенерировать пару приватный/публичный ключ (~/.ssh/server_git и ~/.ssh/server_git.pub) с помощью команды ssh-keygen (надеюсь с этим вы справитесь).

Теперь в репозиторий ssh://server_git@server.com/gitolite-admin.git нужно закинуть ~/.ssh/server_git.pub, и для каждого репозитория добавлять RW+ = server_git, в качестве примера:

repo testing
    RW+     =   insys
    RW+     =   server_git

Хук в Gitolite

Добавляем хук в ~/.gitolite/hooks/common/post-receive следующего содержания:

#!/bin/bash

CURRENT_DIR=`pwd`

/var/www/server_git/data/projects/hook_git.php "$CURRENT_DIR" "$GL_REPO_BASE" "$GL_REPO" >> /var/www/server_dev/data/projects/log.txt 2>&1

exit 0

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

Конфиг вебсервера

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

	...
	ServerName git.intsystem.org
	ServerAlias *.git.intsystem.org
	VirtualDocumentRoot /var/www/server_git/data/www/git.intsystem.org/%1
	...

Создаем новый репозиторий с dev версией

Для начала создаем новый репозиторий в gitolite:

repo testproject
    RW+     =   user
    RW+     =   server_git

Добавляем проект в AutoDeployApp, открываем файл ~/projects/projects.txt, добавляем новый проект:

testproject:testproject:testproject

Создаем новый поддомен для dev версии, создаем каталог ~/www/git.intsystem.org/testproject/.

Теперь любой пуш в ssh://server_git@server.com/testproject.git будет сразу виден по адресу testproject.git.intsystem.org

Немного о production

Идея автоматического применения изменения в продакшн мне не очень нравится, но и каждый раз лазить на сервер через ssh чтобы сделать git pull тоже надоедает. Для этого у меня есть простенький скриптик helper-git. Имеет простейший функционал:

Доступ запаролен (helper-git.php?pass=[pass]), смотрим сам файл

define('ACCESS_PASSWORD', 'doe2njkle');

С виду хоть и выглядит топорно и отчасти по-ламерски, но меня вполне устраивает.

Итог

Итого имеем 4 репозитория на каждый проект:

• Локальный.
• Основной (в который пушим из локального).
• Dev-репозиторий (в него автоматом подтягиваются изменения из основного по хукам).
• Продакшн (в него ручками).

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

Ну в общем вот как то так. Да может не совсем понятно объяснил, но, честно сказать, я сам иногда перестаю понимать как это все работает :)