Скотт Чакон - Pro Git

Преимущества основанных на файлах хранилищ в том, что они просты и используют существующие разграничения прав на файлы и сетевой доступ. Если у вас уже есть общая файловая система, доступ к которой имеет вся команда, настройка репозитория очень проста. Вы помещаете голый репозиторий туда, куда все имеют доступ, и выставляете права на чтение и запись, как вы бы это сделали для любого другого общего каталога. Мы обсудим, как экспортировать голую копию репозитория для этой цели, в следующем разделе: Установка Git на сервер.

Также это хорошая возможность быстро получить наработки из чьего-то рабочего репозитория. Если вы и ваш коллега работаете над одним и тем же проектом, и он хочет, чтобы вы что-то проверили, то запуск команды вроде git pull /home/john/project зачастую проще, чем отправлять и забирать с удалённого сервера.

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

Также важно упомянуть, что не всегда использование общей точки монтирования является быстрейшим вариантом. Локальный репозиторий быстр, только если вы имеете быстрый доступ к данным. Репозиторий на NFS часто медленнее, чем репозиторий через SSH на том же сервере, позволяющий Git использовать на полную локальные диски на каждой системе.

Git может работать через HTTP в двух различных режимах. До версии Git 1.6.6 был только один режим, очень простой и предназначенный только для чтения. В версии 1.6.6 появился новый, более умный режим, позволяющий Git более интеллектуально определять необходимость передачи данных, наподобие того, как это происходит при использовании SSH. В последние годы новый протокол стал очень популярен, так как он проще для пользователя и более эффективен. Новая версия часто называется “Умным” (“Smart”) HTTP, а старая “Тупым” (“Dumb”) HTTP. Мы рассмотрим сначала “умный” протокол.

“Умный” протокол HTTP работает схожим с SSH или Git-протоколами образом, но поверх стандартных HTTP/S портов и может использовать различные механизмы аутентификации HTTP, это часто проще для пользователя, чем что-то вроде SSH, так как можно использовать вещи вроде базовой парольной идентификации вместо установки SSH-ключей.

Он стал, наверное, наиболее популярным способом использования Git, так как может использоваться и для анонимного доступа, как протокол git://, и для отправки изменений с аутентификацией и шифрованием, как протокол SSH. Вместо использования разных адресов URL для этих вещей, можно использовать один для всего. Если вы пытаетесь отослать изменения и репозиторий требует аутентификации (обычно так и есть), сервер может спросить логин и пароль. То же касается и доступа на чтение.

На самом деле для сервисов вроде GitHub, адрес URL который вы используете для просмотра репозитория в браузере (например, “https://github.com/schacon/simplegit[]”) — тот же, который вы можете использовать для клонирования или, если у вас есть доступ, для отправки изменений.

Если сервер не отвечает на умный запрос Git по HTTP, клиент Git попытается откатиться на более простой “тупой” HTTP-протокол. Тупой протокол ожидает, что голый репозиторий Git будет обслуживаться веб-сервером как набор файлов. Прелесть тупого протокола HTTP — в простоте настройки. По сути, всё, что необходимо сделать ― поместить голый репозиторий внутрь каталога с HTTP документами, установить обработчик post-update и всё (см. Git Hooks). Теперь каждый, имеющий доступ к веб-серверу, на котором был размещен репозиторий, может его клонировать. Таким образом, чтобы открыть доступ к вашему репозиторию на чтение через HTTP, нужно сделать что-то наподобие этого:

$cd /var/www/htdocs/

$git clone --bare /path/to/git_project gitproject.git

$cd gitproject.git

$mv hooks/post-update.sample hooks/post-update

$chmod a+x hooks/post-update

Вот и всё. Обработчик post-update, входящий в состав Git по умолчанию, выполняет необходимую команду (git update-server-info), чтобы извлечение (fetch) и клонирование (clone) по HTTP работали правильно. Эта команда выполняется, когда вы отправляете изменения в репозиторий (возможно посредством SSH); Затем остальные могут клонировать его командой

$git clone https://example.com/gitproject.git

В рассмотренном примере мы использовали каталог /var/www/htdocs, обычно используемый сервером Apache, но вы можете использовать любой веб-сервер, отдающий статические данные, расположив голый репозиторий в нужном каталоге. Данные Git представляют собой обычные файлы (в Git изнутри предоставление данных рассматривается более подробно).

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

Мы сосредоточимся на преимуществах умной версии протокола HTTP.

Простота использования одного адреса URL для всех типов доступа и аутентификация только при необходимости делает работу очень простой для конечного пользователя. Возможность аутентификации посредством логина и пароля также даёт преимущество перед SSH, так как пользователям перед использованием не нужно создавать SSH-ключи и загружать публичную часть на сервер. Для неопытных пользователей или пользователей систем, где SSH мало распространён, это большой плюс. Это также очень быстрый и эффективный протокол, сравнимый с SSH.

Вы также можете раздавать доступ к своим репозиториям только для чтения по HTTPS, шифруя содержимое передачи; или вы можете зайти так далеко, что клиенты будут использовать персональные подписанные SSL-сертификаты.

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

На некоторых серверах Git поверх HTTP/S может быть немного сложнее в настройке по сравнению с SSH. Кроме этого, преимущества других протоколов доступа к Git перед “Умным” HTTP незначительны.

Если вы используете HTTP для отправки изменений, удостоверение ваших полномочий зачастую сложнее, чем при использовании SSH-ключей. Но есть несколько инструментов для кеширования полномочий, включая Keychain access на OSX и Credential Manager на Windows, которые вы можете использовать для упрощения процесса. В Хранилище учетных данных кеширование паролей HTTP рассматривается подробнее.

Часто используемый транспортный протокол для хостинга Git — это SSH. Причина этого в том, что доступ по SSH уже есть на многих серверах, а если его нет, то его очень легко настроить. К тому же, SSH — протокол с аутентификацией, и его благодаря распространенности обычно легко настроить и использовать.