Для того чтобы приступить к установке любого сервера Git, вы должны экспортировать существующий репозиторий в новый “голый” репозиторий, т.е. репозиторий без рабочего каталога. Обычно это несложно сделать. Чтобы склонировать ваш репозиторий и создать новый “голый” репозиторий, выполните команду
clone
с параметром --bare
. По существующему соглашению, каталоги с голыми репозиториями заканчиваются на .git
, например:
$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/
Вывод этой команды слегка обескураживает. Поскольку clone
по сути это git init
, а затем git fetch
, мы видим вывод от git init
, который создает пустой каталог. Реальное перемещение объектов не имеет вывода, однако оно происходит. Теперь у вас должна быть копия данных из каталога Git в каталоге my_project.git
.
Грубо говоря, это что-то наподобие этого:
$ cp -Rf my_project/.git my_project.git
Тут есть пара небольших различий в файле конфигурации, но в вашем случае эту разницу можно считать несущественной. Можно считать, что в этом случае берется собственно репозиторий Git без рабочего каталога, и создается каталог только для него.
Размещение “голого” репозитория на сервере
Теперь, когда у вас есть голая копия вашего репозитория, все что вам нужно сделать это поместить ее на сервер и настроить протоколы. Условимся, что вы уже настроили сервер git.example.com, имеете к нему доступ по SSH и хотите размещать все ваши репозитории Git в каталоге/opt/git
. Вы можете добавить ваш новый репозиторий копированием голого репозитория:
$ scp -r my_project.git user@git.example.com:/opt/git
Теперь другие пользователи, имеющие доступ к серверу по SSH и право на чтение к каталогу /opt/git
, могут склонировать ваш репозиторий выполнив:
$ git clone user@git.example.com:/opt/git/my_project.git
Если у пользователя сервера есть право на запись в каталог /opt/git/my_project.git
, он автоматически получает возможность отправки изменений в репозиторий. Git автоматически добавит право на запись в репозиторий для группы, если вы запустите команду git init
с параметром --shared
.
$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared
Видите, это просто взять репозиторий Git, создать “голую” версию и поместить ее на сервер, к которому вы и ваши коллеги имеете доступ по SSH. Теперь вы готовы работать вместе над одним проектом.
Важно отметить, что это практически всё, что вам нужно сделать чтобы получить рабочий Git-сервер, к которому несколько человек имеют доступ ― просто добавьте учетные записи SSH на сервер, и положите голый репозиторий в место, к которому эти пользователи имеют доступ на чтение и запись. И всё.
Из нескольких последующих разделов вы узнаете, как получить более сложные конфигурации. В том числе как не создавать учетные записи для каждого пользователя, как сделать публичный доступ на чтение репозитория, как установить веб-интерфейс, как использовать Gitosis, и др. Однако, помните, что для совместной работы пары человек на закрытом проекте, всё, что вам нужно ― это SSH-сервер и “голый” репозиторий.
Малые установки
Если вы небольшая фирма, или вы только пробуете Git в вашей организации и у вас мало разработчиков, то все достаточно просто. Один из наиболее сложных аспектов настройки сервера Git ― управление пользователями. Если вы хотите чтобы некоторые репозитории были доступны некоторым пользователям только на чтение, а другие и на чтение и на запись, вам может быть не очень просто привести права доступа в порядок.SSH доступ
Если у вас уже есть сервер, к которому все ваши разработчики имеют доступ по SSH, проще всего разместить ваш первый репозиторий там, поскольку вам не нужно практически ничего делать (как мы уже обсудили в предыдущем разделе). Если вы хотите более сложного управления правами доступа к вашим репозиториям, вы можете сделать это обычными правами файловой системы, предоставляемыми операционной системой вашего сервера. Если вы хотите разместить ваши репозитории на сервер, на котором нет учетных записей для каждого в вашей команде, кому нужен доступ на запись, вы должны настроить доступ по SSH для них. Будем считать, что если у вас есть сервер, на котором вы хотите это сделать, то SSH-сервер на нем уже установлен, и через него вы имеете доступ к серверу. Есть несколько способов дать доступ каждому в вашей команде. Первый — настроить учетные записи для каждого. Это просто, но может быть весьма обременительно. Вероятно, вы не захотите для каждого пользователя выполнять adduser и задавать временные пароли. Второй способ ― создать на машине одного пользователя ‘git
’, попросить каждого пользователя, кому нужен доступ на запись, прислать вам публичный ключ SSH, и добавить эти ключи в файл ~/.ssh/authorized_keys
вашего нового пользователя ‘git
’. Теперь все будут иметь доступ к этой машине через пользователя ‘git
’. Это никак не повлияет на данные коммита ― пользователь, под которым вы соединяетесь с сервером по SSH, не затрагивает сделанные вами коммиты.
Другой способ сделать это ― использовать SSH-сервер, аутентифицирующий по LDAP-серверу или любому другому централизованному источнику, который у вас может быть уже настроен. Любой способ аутентификации по SSH, какой вы только сможете придумать, должен работать, если пользователь может получить доступ к консоли.
Pro Git