Ваш вопрос ориентирован на обсуждение книги Git Pro, которое на самом деле, технически, главным образом касается того, что, как мне кажется, должно называться транспорт , а не протоколов. Книга Git Pro не входит в это различие (по крайней мере, в то время, когда я пишу этот ответ); и текущая документация по Git. Но Git 2.18 представил новый проводной протокол (с кодом разрешения, впервые появившимся в Git 2.16 ), поэтому я думаю, что для ответа на этот вопрос нужен еще один ответ.
В частности, Git имеет дурную привычку объединять аутентификацию , разрешения , транспортирует (в смысле «транспортного уровня» в сетевом стеке). ) и протокол (что Git использует для Git-to-web-сервера или одноранговой связи). Это работает до сих пор для Git, потому что:
- Локальный (
file:// или необработанный путь) спецификатор приводит к использованию локальных методов, которые не выполняют аутентификацию и полагаются на разрешения ОС. 1 Поскольку ваш Git просто общается сам с собой, он просто имеет согласиться с тем, что говорит сам себе.
- Спецификаторы
http:// и https:// используют libcurl и внешние аутентификаторы для выполнения аутентификации (если они вообще это делают). 2 После этого они полагаются на разрешения ОС. Поскольку Git общается с веб-сервером, он должен переправлять свой собственный протокол через интерфейс REST сервера. Между тем сам веб-сервер предоставляет транспортный протокол.
- Спецификатор
ssh:// использует ssh, как правило, из библиотеки, предоставленной ОС, для аутентификации и транспорта. 3 ОС на другом конце обеспечивает любую проверку разрешений в обычных случаях. (Особые случаи, такие как Gitolite и GitHub-ssh-access, используют другие уловки за кулисами, все вне сферы действия Git.)
- Спецификатор
git:// использует упрощенный протокол поверх TCP в качестве транспортного протокола. Он не выполняет аутентификацию и не проверяет разрешения. Он предназначен только для чтения: ему не нужно ничего контролировать, кто может толкать, поскольку никто не может толкать. 4
До Git 2.16 действительно был только один протокол Git Wire. (Так называемый «тупой протокол» специфичен для использования веб-серверов, и даже тогда, только когда они не могут запустить реальный протокол. Действительно, тупой протокол сводится к возможности загружать отдельные файлы с веб-сервера - вот и все !) Однако в Git 2.16 Git научился запрашивать конкретную версию протокола.
Таким образом, существующий интеллектуальный протокол стал нулевой версией протокола Git. Протокол Git версии 1 был сразу определен как выполняющий ту же функцию, так что можно протестировать код выбора версии протокола, не добавляя ничего другого.
В Git 2.18, однако, теперь есть версия протокола 2. Протокол 2 все еще определяется, но первый и, возможно, самый полезный (по крайней мере, для некоторых) трюк, который у него есть, - это возможность перечислять меньше ссылок. Например, соединение с большим старым Git-репозиторием, имеющим много тегов, может привести к значительным потерям пропускной способности. На странице блога Google есть много хороших деталей .
Пока что этот вид нумерации протоколов по-прежнему в основном для разработчиков Git, но, вероятно, скоро станет важным.
1 Стоит отметить, что разрешения ОС в системах POSIX (Linux, различные BSD и т. Д.) Допускают user , group и другие разрешения. Здесь «пользователь» означает числовой идентификатор пользователя того, кто выполняет различные команды, «группа» означает числовой идентификатор группы, а «другой» означает любого, кто сначала не соответствует «пользователю» или «группе». То есть фактические разрешения определяются тем, какие из этих трех сначала соответствуют идентификаторам текущего пользователя.
Несмотря на то, что Git не так хорош, как полноценные ACL-списки, они используют эти разрешения, чтобы позволить ОС обрабатывать как локальную (тот же хост), так и удаленную (любой сетевой транспорт) проверку разрешений. В частности, вы можете настроить core.sharedRepository на group или all или подключить к определенному значению POSIX umask . Подробнее см. документацию git config .
2 Обратите внимание, что https:// может использовать SSL / TLS и осуществлять обмен зашифрованными данными. То есть операции REST и все данные, отправляемые после подключения Git по любому протоколу, который Git будет использовать, хранятся в секрете от промежуточных сайтов, при условии, что никто не нарушает шифрование. В Git есть несколько регуляторов конфигурации, поставляемых в libcurl (хотя до libcurl до используйте их). См. Все настройки http.* в git config. Безопасность SSL сложна; см. ссылку в сноске 3.
3 Транспортировка SSH зашифрована по протоколу SSL / TLS, хотя детали отличаются. Для получения дополнительной информации см. Разница между SSH и SSL, особенно в терминах "SFTP" и "FTP через SSL" .
4 Как отмечается в комментарии kostix , вы можете включить перенос по git:// транспортам. Это кажется мне очень плохой идеей, именно , потому что не имеет аутентификации и проверки прав доступа. Обратите внимание, что проверка разрешений на уровне ОС фактически закорочена, поскольку демон Git, обслуживающий запросы git://, работает как один конкретный идентификатор пользователя, обычно git-daemon.