Скотт Чакон - Pro Git
- Название:Pro Git
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Скотт Чакон - Pro Git краткое содержание
В книге рассматриваются следующие темы: основы Git;
ветвление в Git;
Git на сервере;
распределённый Git;
GitHub;
инструменты Git;
настройка Git;
Git и другие системы контроля версий.
Pro Git - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
$git add .
$git commit -m 'initial commit'
$git remote add origin git@gitserver:/opt/git/project.git
$git push origin master
Теперь остальные могут клонировать его и отправлять (push) туда изменения так же легко:
$git clone git@gitserver:/opt/git/project.git
$cd project
$vim README
$git commit -am 'fix for the README file'
$git push origin master
Этим способом вы можете быстро получить Git-сервер с доступом на чтение/запись для небольшой группы разработчиков.
Заметьте, что теперь все эти пользователи могут заходить на сервер как пользователь git. Чтобы это предотвратить, нужно изменить ему оболочку на что-то другое в файле passwd.
Вы можете легко ограничить пользователя git только действиями, связанными с Git, с помощью ограниченной оболочки git-shell, поставляемой вместе с Git. Если вы выставите её в качестве командного интерпретатора пользователя git, то этот пользователь не сможет получить доступ к обычной командной оболочке на вашем сервере. Чтобы её использовать, укажите git-shell вместо bash или csh в качестве командной оболочки пользователя. Для этого вы должны сначала добавить git-shell в /etc/shells если её там ещё нет:
$cat /etc/shells # посмотрим, присутствует ли `git-shell`. Если нет...
$which git-shell # проверим, что git-shell установлена.
$sudo vim /etc/shells # и добавим путь к git-shell из предыдущей команды
Теперь можно изменить оболочку для пользователя используя chsh :
$sudo chsh git # и вводим путь к git-shell, обычно /usr/bin/git-shell
Теперь пользователь git может использовать SSH соединение только для работы с репозиториями Git и не может зайти на машину. Вы можете попробовать и увидите, что вход в систему отклонен:
$ssh git@gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
Теперь сетевые команды Git будут работать, но пользователи не смогут заходить на сервер. Как указывает вывод, вы также можете изменить домашний каталог пользователя git, чтобы немного изменить поведение git-shell. Например, вы можете ограничить команды Git, которые сервер будет принимать или сообщение которое увидят пользователи если попробуют зайти по SSH. Запустите git help shell для получения дополнительной информации.
Git-демон
Далее мы установим демон, обслуживающий репозитории по протоколу “Git”. Это широко распространённый вариант для быстрого доступа без аутентификации. Помните, что раз сервис — без аутентификации, всё, что обслуживается по этому протоколу — публично доступно в сети.
Если вы запускаете демон на сервере не за сетевым экраном, он должен использоваться только для проектов, которые публично видны внешнему миру. Если сервер находится за вашим сетевым экраном, вы можете использовать его для проектов, к которым большое число людей или компьютеров (серверов непрерывной интеграции или сборки) должно иметь доступ только на чтение, и если вы не хотите для каждого из них заводить SSH-ключ.
В любом случае, протокол Git относительно просто настроить. Упрощённо, вам нужно запустить следующую команду в демонизированной форме:
git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
--reuseaddr позволит серверу перезапуститься без ожидания истечения старых подключений, --base-path позволит людям не указывать полный путь, чтобы склонировать проект, а путь на конце говорит демону Git, где искать экспортируемые репозитории. Если у вас запущен сетевой экран, вы должны проколоть в нём дырочку, открыв порт 9418 на машине, где всё это запущено.
Вы можете демонизировать этот процесс несколькими путями, в зависимости от операционной системы. На машине с Ubuntu используйте Upstart-сценарий. Итак, в этом файле
/etc/event.d/local-git-daemon
поместите такой сценарий:
start on startup
stop on shutdown
exec /usr/bin/git daemon \
--user=git --group=git \
--reuseaddr \
--base-path=/opt/git/ \
/opt/git/
respawn
По соображениям безопасности крайне приветствуется, если вы будете запускать этого демона от имени пользователя с правами только на чтение репозиториев — вы легко можете сделать это, создав пользователя git-ro и запустив этого демона из-под него. Для простоты мы запустим его от того же пользователя git , от которого запущен git-shell.
Когда вы перезапустите машину, Git-демон запустится автоматически, и перезапустится, если вдруг завершится. Чтобы запустить его без перезагрузки машины, выполните следующее:
initctl start local-git-daemon
На других системах вы можете использовать xinetd, сценарий вашей системы sysvinit, или что-то другое — главное, чтобы вы могли эту команду как-либо демонизировать и присматривать за ней.
Затем нужно указать Git, к каким репозиториям предоставить неаутентифицированный доступ через Git-сервер. Вы можете сделать это для каждого репозитория, создав файл с именем git-daemon-export-ok.
$cd /path/to/project.git
$touch git-daemon-export-ok
Наличие этого файла скажет Git’у, что можно обслуживать этот проект без аутентификации.
Умный HTTP
Теперь у нас есть доступ с аутентификацией через SSH и неаутентифицированный доступ через git://, но есть ещё протокол, который может делать и то и другое. Настройка умного HTTP — это просто установка CGI-скрипта git-http-backend, поставляемого с Git, на сервер . Этот CGI-скрипт будет читать путь и заголовки, посылаемые git fetch или git push в URL и определять, может ли клиент работать через HTTP (это верно для любого клиента, начиная с версии 1.6.6). Если CGI-скрипт видит, что клиент умный, то и общаться с ним будет по-умному, иначе откатится на простое поведение (так что он обратно совместим по чтению со старыми клиентами).
Давайте пройдёмся по самой базовой установке. Мы настроим Apache как сервер CGI. Если у вас не установлен Apache, вы можете сделать это на Linux-машине примерно так:
$sudo apt-get install apache2 apache2-utils
$a2enmod cgi alias env
Это также включит модули mod_cgi, mod_alias и mod_env, необходимые для корректной работы.
Далее мы добавим некоторые вещи в конфигурационный файл Apache, чтобы запускать git-http-backend как обработчик для всего по пути /git на веб-сервере.
SetEnv GIT_PROJECT_ROOT /opt/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
Если пропустить переменную GIT_HTTP_EXPORT_ALL, тогда Git будет отдавать только неаутентифицированным клиентам репозитории с файлом git-daemon-export-ok внутри, также как делает Git-демон.
Далее нужно сказать Apache разрешить запросы к этому пути примерно так:
Options ExecCGI Indexes
Order allow,deny
Allow from all
Require all granted
Наконец, нужно как-то аутентифицировать запись, например с помощью такого блока Auth:
AuthType Basic
AuthName "Git Access"
AuthUserFile /opt/git/.htpasswd
Require valid-user
Это потребует создания файла .htaccess с паролями всех пользователей. Вот пример добавления пользователя “schacon” в этот файл:
$htdigest -c /opt/git/.htpasswd "Git Access" schacon
Есть множество путей аутентифицировать пользователей Apache, придётся выбрать и реализовать один из них. Это просто простейший пример, который можно привести. Вы также почти наверняка захотите настроить SSL, чтобы все данные были зашифрованы.
Читать дальшеИнтервал:
Закладка: