что такое сервер git
Как настроить собственный сервер Git
Если вы хотите настроить систему управления версиями для проекта, но предпочитаете не размещать его в сервисе, таком как GitHub, вы можете запустить свой собственный сервер git на VPS, чтобы хранить свой код и действовать как главный репозиторий для всех соавторов.
Зачем запускать собственный сервер?
С учётом того, сколько существует бесплатных поставщиков для размещения Git, таких как GitHub, GitLab и Bitbucket, нет смысла делать это самостоятельно. Но есть несколько ситуаций, когда это действительно нужно.
Во-первых, запуск собственного сервера гораздо более конфиденциальный, особенно если вы работаете над кодом, который не хотите хранить в чужом «облаке». Нельзя сказать, что такие провайдеры, как GitLab, небезопасны, но размещение всего на собственном сервере может дать некоторым людям больше спокойствия.
Кроме того, если вы используете стороннюю службу, существуют ограничения на размер файла, которые могут быть неидеальными. GitHub не поддерживает файлы размером более 100 МБ, что может стать серьёзной проблемой для проектов с большими двоичными файлами. Использование собственного сервера снимает этот предел, если вы можете заплатить за больше места на жёстком диске.
Каким бы ни был ваш случай использования, вы, вероятно, сможете получить большей функций, чем в git без платной подписки. GitLab Community Edition — это бесплатная версия с открытым исходным кодом, которую легко установить на вашем собственном сервере. Это даёт вам все преимущества самостоятельного размещения, а также очень приятный веб-интерфейс и многочисленные инструменты CI/CD. Мы настоятельно рекомендуем вам использовать GitLab, если у вас есть свободное место на сервере. Для него требуется около 3 ГБ ОЗУ. Вы можете прочитать наше руководство по его установке и настройке, чтобы узнать больше.
Но если вам не нужны все навороты и вы просто хотите запустить простой git remote, то продолжайте читать это руководство.
git remote — это просто чей-то ещё репозиторий
Первое, что следует отметить в отношении git, это то, что размещение сервера на самом деле не очень сложно. Git использует модель распределенного контроля версий; ваш локальный клон репозитория вообще не подключается ко всем вашим коллегам, но он подключается к «удалённому», обычно на внешнем центральном сервере или службе. Когда вы push (отправляете изменения) и pull (скачиваете изменения), вы вносите изменения в официальную главную копию remote. Когда ваши коллеги получают данные с remote, они скачивают ваши commit’ы.
Технически вы можете запустить git как полностью децентрализованный сервис. Если бы у вас было два человека, каждый из них получал бы обновления друг от друга. (Отправка в репозитории, не являющиеся серверными, в этой настройке не рекомендуется.) На практике это нецелесообразно, если обе стороны не имеют статических IP-адресов и всегда находятся в сети, поэтому большинство людей выбирают модель сервер-клиент.
Итак, всё, что представляет собой сервер git, – это просто обычный репозиторий, который настроен как главная копия и открыт для Интернета. Настроить на удивление просто. Во-первых, нам нужно создать нового пользователя. Git использует SSH для аутентификации и шифрования всего трафика между серверами и клиентами, поэтому нам понадобится пользователь службы для управления репозиторием.
Затем переключитесь на пользователя git для остальной части настройки:
Вам нужно будет добавить свои SSH-ключи в файл authorized_keys пользователя git:
Управлять доступом таким способом нелегко, так как вам нужно предоставить всем доступ к одному и тому же пользователю службы, что не идеально, или вам нужно будет настроить отдельных пользователей для каждого человека, что также не идеальный вариант. В любом случае коммиты будут отображаться с любым именем пользователя и адресом электронной почты, которые конечный пользователь настроил в своих настройках git.
В любом случае, чтобы создать реальный репозиторий, просто запустите git init в домашнем каталоге пользователя git:
Здесь необходим параметр —bare. Обычно, когда вы клонируете репозиторий, git хранит все файлы, которые он использует для управления версиями, в скрытой папке .git, а также сохраняет пригодную для использования версию там, где находится ваш текущий извлечённый HEAD. Обычно это делает вашу папку репо примерно вдвое больше, чем она была бы без git, хотя она может быть ещё больше, если у вас есть большие двоичные файлы и много изменений с течением времени.
Это всё, что требуется на стороне сервера. Со своего локального компьютера вам нужно будет клонировать репо или добавить новый remote:
URL-адрес начинается с git@, потому что он подключается через SSH как пользователь git.
example.com — это адрес вашего сервера, который можно указать как имя хоста или IP
:repository.git в конце на самом деле является именем пути, а не просто идентификатором. Путь указывается относительно домашнего каталога пользователя git, поэтому, если вы разместили репозиторий в другом месте, то вам нужно указать абсолютный путь.
После того, как вы подключили локальное репо, у вас должен быть полный доступ для push и pull в обычном режиме. Имейте в виду, что git по умолчанию не имеет встроенной системы разрешений, поэтому ничто не мешает любому, у кого есть доступ к пользователю git, иметь полный контроль над вашим главным репозиторием.
Что такое Git: объясняем на схемах
Команды разработчиков пользуются системой контроля версий. Чаще всего это Git. Разбираемся, что это значит, зачем нужно и как устроено.
Git — это система для управления версиями исходного кода программ. В статье мы познакомимся с её основными возможностями, покажем отличие от GitHub и объясним, зачем Git новичку. Ещё вы узнаете, с чего начать обучение и почему не стоит тратить время на альтернативные программы.
Git — это система коммитов
Представьте ситуацию: геймер доходит до финала, проигрывает и возвращается к началу уровня — попадает в ближайшую контрольную точку игры, где разработчики разрешили сохраниться. Если мы уберём контрольные точки, после каждого проигрыша придётся начинать игру заново.
В программировании за сохранение кода в контрольных точках отвечает система контроля версий — специальная технология, которую можно подключить к любому проекту. Система контроля версий страхует от ошибок и возвращает код в то состояние, когда всё работало.
Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.
Git — это комплекс связанных веток
Коммиты располагаются на master-ветке — основной версии проекта, которая после завершения работы превратится в продукт.
Система контроля версий позволяет создавать ответвления от master-ветки и экспериментировать с проектом, не мешая другим участника команды.
Возьмём предыдущую схему, где мы обнаружили ошибку и откатились на один коммит назад. Чтобы поправить код, создадим несколько дополнительных веток и в каждой протестируем разные варианты решения проблемы. Когда решение найдено, ветку с правильным кодом переносим в master-ветку и сохраняем коммит. Лишние ветки оставляем или удаляем, поскольку они не влияют на проект и скрыты от других разработчиков — это ваш личный черновик.
Git — это инструмент совместного создания кода
Часто бывает так: разработчики отделяются от master-ветки и работают над частью проекта самостоятельно — например, чтобы протестировать дополнительные функции. Но не могут продолжить, пока кто-то из команды не допишет код.
Система контроля версий позволяет не ждать обновления master-ветки и разрешает всем участникам команды свободно перемещаться между ветками других разработчиков для копирования нужных фрагментов кода.
Бывают и обратные ситуации, когда несколько разработчиков одновременно дописывают код, заливают его в master-ветку и сталкиваются с конфликтом — один файл получает несколько несогласованных изменений. В этом случае Git попробует автоматически исправить ошибки. Если не получится, разработчики это увидят и смогут поправить код вручную.
Git — это распределённая система версий
Системы контроля версий бывают локальными, централизованными или распределёнными.
Из-за удобства и гибкости распределённая система версий Git считается современным форматом. Это стандарт для большинства ИТ-команд.
Git — это не GitHub
Git — это программа, которую нужно установить и подключить к проекту для управления системой контроля версий. GitHub — это сайт-хранилище для историй версий проектов: вы подключаете Git, регистрируетесь на GitHub, создаёте онлайн-репозиторий и переносите файлы с Git на GitHub.
Git — это самая популярная система контроля версий, а GitHub — онлайн-хранилище кода. Git и GitHub настроены на взаимодействие и поэтому часто используются как единый механизм работы с проектом.
Если нужно, Git можно заменить альтернативной программой контроля версий, а GitHub — другим онлайн-хранилищем кода. Большинству работодателей это не нужно, поскольку знакомство с другими сервисами отнимает время и неудобно многим разработчикам.
Зачем новичку учить Git
Git используется в большинстве компаний, где над проектом работает хотя бы два разработчика:
Это общая схема того, как проходит командная работа в проекте. В ней не учтены правила использования Git, которые каждая команда пишет под себя. Например, у каждой команды свой порядок проверки кода и свои критерии его готовности для добавления в master-ветку.
Знание Git и знание правил использования Git в команде — это два разных навыка, которые можно сравнить с умением ездить на автомобиле и знанием правил дорожного движения. Если умеете управлять автомобилем — вам проще сконцентрироваться и быстро выучить правила. С Git аналогичная ситуация: если вы умеете управлять системой контроля версий, то можете сразу влиться в проект, не отвлекаться на второстепенные вещи и сосредоточиться на качестве кода.
С чего начать: 3 шага, чтобы освоить Git
1. Посмотрите наш вебинар по основам работы с Git:
Простая установка сервера GIT на Windows
Предисловие или от куда взялась «бредовая» идея ставить Git на Windows
Я работаю в одной не очень большой IT-компании, которая продает свои и чужие программные решения, занимается проектами внедрения, оказывает клиентскую поддержку, проводит обучение и далее все такое в том же духе. До недавнего времени в моей маленькой команде разработки все было неплохо организовано и у нас даже был свой собственный достаточно мощный сервер. Но случилось непредвиденное и по воле злого рока один из серверов фирмы полетел, а руководство решило вместо него в стойку поставить наш сервер отдела разработки. Нам предложили «временно» переехать на любой из серверов общего назначения.
А теперь внимание! Только мы одни во всей фирме работаем на Линуксе, а все остальные сидят исключительно на Windows и сервера у нас тоже под управлением серверных редакций ОС от Билла Гейтса. И если перенос базы Redmine не вызывает особых вопросов, то задача поднять на сервере Windows сервер для Git меня сразу поставила в тупик. Но несколько часов потраченных на поиски дали мне простое работающее решение.
Изучение матчасти
Git умеет работать с четырьмя сетевыми протоколами для передачи данных: локальный, Secure Shell (SSH), Git и HTTP.
Первый вариант я не стал рассматривать, так как он подразумевает наличие сетевой шары открытой для общего доступа. Допустим, что с помощью групповых политик домена можно обезопасить данные от случайного удаления продавцем-стажером. Но как работать из дому? Ради нескольких «коммитов выходного дня» поднимать VPN?
Читаем далее и видим:
SSH — единственный из сетевых протоколов, предоставляющий доступ и на чтение, и на запись. Два других сетевых протокола (HTTP и Git) в большинстве случаев дают доступ только на чтение, поэтому даже если они вам доступны, вам всё равно понадобится SSH для записи.
Путь к конечной цели уже стал менее туманным: сначала требуется поставить сервер SSH, а далее установить одну из многочисленных сборок Git для Windows (официальную msysgit, Git Extensions, TortoiseGit, QGit и т.д.)
Выбор сервера SSH для Windows
Воспользовавшись поисковиком по сети Internet, я сделал небольшую подборку текущих реализаций SSH под Windows. Не претендую на то, что смог найти все решения в этой области, но самые популярные точно не пропустил. Итак:
Cygwin. В рамках проекта переноса функциональности Linux на Windows был портирован в том числе и OpenSSH. Библиотека проекта cygwin1.dll с реализацией SSH так же используются в большинстве других решений. Простую инструкцию с картинками по установке и настройке можно посмотреть тут. А так же рекомендую к прочтению статью из журнала «Windows IT Pro» № 7 за 2001 год — SSH в Windows.
freeSSHd. Лидер среди упоминается на форумах. Характеризуется как легкий в использовании. Лицензия позволяет бесплатно использовать в коммерческих целях. Нашел инструкцию по установке и настройке на Win2008.
WInSSHD. Самое богатое по функциональности из увиденных мною реализаций. Это хорошее профессиональное решение для обеспечения безопасности. Но для моего гвоздя — это микроскоп. Если кого-то продукт заинтересовал, то у них есть 30-дневная ознакомительная полная версия и возможность бесплатного частного использования.
KpyM Telnet/SSH Server. Плохих отзывов не заметил. Но меня смущает, что их сайт не обновляется с 2009 года, а так же на официальном форуме как-то безжизненно. С другой стороны, если продукт бесплатный и выполняет свою работу, то нет смысла заниматься развитием. Понравилось наличие в их FAQ списка других решений для SSH под Windows. Рекомендую заглянуть.
Copssh. Продукт от норвежской компании ITeF!X, в котором они к windows-реализации OpenSSH добавили красивый GUI-интерфейс администратора и некие «best practices». Именно это решение, более всего рекомендуется в обсуждении поднятия сервера Git под Windows на StackOverflow.
Случайная находка
Собственно под впечатлением ответов на StackOverflow я уже расслабился и решил было пойти проторенной моими предшественниками дорожкой. Но при изучении сайта компании ITeF!X я обнаружил, что у них есть и более подходящий для моих целей продукт — gitwin. Это оказался тот самый требуемый мне сервер Git под Windows.
Я вначале не поверил глазам — если такой чудо продукт существует, то почему о нем до сих пор не трубят на каждом шагу. Ответ нашелся в новостях компании — как оказалось программный продукт только полмесяца назад (11 октября 2013 года) выложили в общий доступ. Точнее на днях выложили бесплатную для использования версию. Платная существовала и раньше, но видимо не пользовалась особым спросом (с января 2012 года на официальном форуме компании всего две созданные темы в разделе gitwin).
Еще один раздел выделили для описания использования. Тут описали активацию нового пользователя для доступа по SSH, создание пары ключей и пустого репозитория. И так же кроме описания текстом дают записанный обучающий ролик:
Установка, настройка и тестирование сервера Git
Я установил на наш сервер gitwin редакции «free edition» и могу поделится только этим опытом.
1. Начинаем со скачивания инсталятора со странички продукта.
2. Запускаем инсталятор и нас спрашивают куда устанавливать продукт. Я оставил по-умолчанию в «C:\Program Files (x86)\ICW». Зачем может понадобится менять путь? Дело в том, что этот каталог станет корнем для линуксовых утилит и домашний каталог пользователя git тоже будет создан тут же «C:\Program Files (x86)\ICW\home\git\». Если есть предчувствие проблем с правами доступа, то можете поменять на менее проблемный для вас каталог.
3. В процессе установки выводятся сообщения о создании двух пользователе «SvcCOPSSH» и «git». Под первым пользователем будет работать служба «OpenSSHServer», а второй нужен собственно для обслуживания репозиториев. Пароли к этим пользователям можно узнать в конце процесса установки, если нажать на «Show details». Советую по правому щелчку скопировать вывод в буфер и сохранить на всякий случай.
3.1. Перепроверка состава пользователей показала, что инсталятор втихую создал еще одного пользователя — «sshd» с описанием «copSSH privilege separation user» и сам же отключил его. Не понятно и подозрительно…
4. Скорее всего из-за редакции «free edition» дальнейшие шаги отличались от описанных на сайте. Вместо консоли администрирования в меню Пуск/copssh поместили два пункта «01. Activate a user» и «02. Deactivate a user». Но суть процесса от этого не изменилась. Запускаем «01. Activate a user» и указываем пользователя для активации (в моем случае все тот же git), выбираем командную оболочку (выбор из bash, sftponly и false) и ставим опциональные галочки. Тут читаем внимательно:
4.1. Если нам нужна пара ключей, то оставляем включенную по-умолчанию «Create keys for public key authentication». При парольной авторизации можете снять…
4.2. Если у пользователя планируется использование его родного пользовательского каталога из C:\Users\ (или может у кого-то до сих пор C:\Documents and Settings\) тогда оставляем включенные по-умолчанию галочки «remove copssh home directory if it exists» и «Create link to user’s real home directory». Я рискнул их снять и таким образом все репозитории у меня будут запрятаны глубоко в системном каталоге Program Files.
5. После активации пользователя и создания ключей можем протестировать всю систему на работоспособность. Выбираем в меню Пуск/copssh пункт «03. Start a Unix BASH Shell» и создаем пустой репозиторий. Я не стал блистать остроумием и повторил команду с официального сайта:
6. Далее тестирование переехало на мой рабочий ноут. Я успешно склонировал пустой репозиторий, закинул в него несколько файлов и запушил назад. Проблем не возникло. Перешел в другой каталог и снова склонировал репозиторий — на этот раз он был уже не пустой и содержал мой коммит с файликами. Таким образом с моей рабочей станции различия между работой с репозиторием Git на предыдущем сервере Ubuntu и на новом сервере Windows замечено не было!
Заключение
Удачно найденный gitwin оказался именно тем решением, которое я искал — запускается под Windows и создает иллюзию для пользователей, что они работают с полноценным удаленным репозиторием. Глюков пока не заметил. Но если обнаружу, то обязательно дополню данную статью.
Надеюсь, что собранные материалы окажутся кому-нибудь полезными. И хочу пожелать не боятся потратить несколько часов на поиски, если вы не уверены, что в вашей голове наиболее актуальная информация. Ведь если бы я изначально зашел на StackOverflow и выполнил все по детальному пошаговому руководству от Тима Дэвиса, то не узнал бы о существовании более короткого пути, когда вся инфраструктура поднимается и настраивается буквально в десяток кликов мышкой. Успехов!
Послесловие. Истории успехов от хабраюзеров
Я подобно Сократу с каждым новым квантом знаний понимаю как еще много того, чего я все еще не знаю. В комментариях коллеги описывают положительный опыт на заданную мною тему, который грех игнорировать. Итак:
A1lfeG вместе со своей командой далеки от Linux’а, но тем не менее ихняя установка центрального репозитория Git’а была довольно простой. В этом им помог продукт SCM Manager.
IamKarlson хорошо отзывается о решении Bonobo Git Server, которое используется у него на работе. Как плюс для себя отмечу использование веб-сервера IIS, который у нас уже работает.
Установка Git на сервер
Рассмотрим теперь установку сервиса Git с поддержкой этих протоколов на сервер.
Здесь мы приводим команды и шаги, необходимые для базовой, упрощённой установки на Linux-сервер, но эти сервисы можно запустить и на MacOS или Windows сервере. На самом деле, установка боевого сервера в вашей инфраструктуре неминуемо будет иметь отличия в настройках безопасности или инструментах операционной системы, но мы надеемся дать вам общее понимание происходящего.
Грубо говоря, это эквивалентно команде:
Тут есть пара небольших различий в файле конфигурации, но в нашем случае эту разницу можно считать несущественной. В этом случае берётся репозиторий Git без рабочего каталога и помещается в отдельный каталог.
Размещение голого репозитория на сервере
Видите, как это просто, взять репозиторий Git, создать голую версию и поместить ее на сервер, к которому вы и ваши коллеги имеете доступ по SSH. Теперь вы готовы работать вместе над одним проектом.
Малые установки
Если вы небольшая компания или вы только пробуете использовать Git в вашей организации и у вас небольшое число разработчиков, то всё достаточно просто. Один из наиболее сложных аспектов настройки сервера Git — это управление пользователями. Если вы хотите, чтобы некоторые репозитории были доступны определенным пользователям только на чтение, а остальным на чтение и запись, то настроить доступ и привилегии будет несколько сложнее.
SSH доступ
Если у вас уже есть сервер, к которому все ваши разработчики имеют доступ по SSH, проще всего разместить ваш первый репозиторий там, поскольку вам не нужно практически ничего делать (как мы уже обсудили в предыдущем разделе). Если вы хотите более сложного управления правами доступа к вашим репозиториям, вы можете сделать это обычными правами файловой системы, предоставляемыми операционной системой вашего сервера.
Если вы хотите разместить ваши репозитории на сервере, где нет учётных записей для членов команды, которым требуются права на запись, то вы должны настроить доступ по SSH для них. Будем считать, что если у вас для этого есть сервер, то SSH-сервер на нем уже установлен и через него вы получаете доступ.
Есть несколько способов предоставить доступ всем участникам вашей команды. Первый — создать учётные записи для каждого, это просто, но может быть весьма обременительно. Вероятно, вы не захотите для каждого пользователя выполнять adduser (или useradd ) и задавать временные пароли.
Другой способ сделать это — настроить SSH сервер на использование аутентификации через LDAP-сервер или любой другой имеющийся у вас централизованный сервер аутентификации. Вы можете использовать любой механизм аутентификации на сервере и считать что он будет работать для Git, если пользователь может получить доступ к консоли по SSH.
К этому моменту вы уже должны уметь делать большую часть повседневных задач, для которых вы будете использовать Git. Однако, для совместной работы в Git, вам необходим удалённый репозиторий. Несмотря на то, что технически вы можете отправлять и забирать изменения непосредственно из личных репозиториев, делать это не рекомендуется. Вы легко можете испортить то, над чем работают другие, если не будете аккуратны. К тому же, вам бы наверняка хотелось, чтобы остальные имели доступ к репозиторию даже если ваш компьютер выключен, поэтому наличие более надёжного репозитория обычно весьма полезно. Предпочтительный метод взаимодействия с кем-либо — это создание промежуточного репозитория, к которому вы оба будете иметь доступ, и отправка и получение изменений через него.
Запустить Git-сервер достаточно просто. Для начала следует выбрать протокол, который вы будете использовать для связи с сервером. Доступные протоколы с их достоинствами и недостатками описываются в первой части этой главы. Следующие части освещают базовые конфигурации с использованием этих протоколов, а также настройку вашего сервера для работы с ними. Далее мы рассмотрим несколько вариантов готового хостинга, которые можно использовать, если вы не против разместить ваш код на чужом сервере и не хотите мучиться с настройками и поддержкой вашего собственного сервера.
Если вас не интересует настройка собственного сервера, вы можете перейти сразу к последней части этой главы для настройки аккаунта на Git-хостинге, а затем перейти к следующей главе, где мы обсудим различные аспекты работы с распределенной системой контроля версий.
Удалённый репозиторий — это обычно голый (чистый, bare) репозиторий — репозиторий Git, не имеющий рабочего каталога. Поскольку этот репозиторий используется только для обмена, то нет причин создавать рабочую копию файлов на диске — достаточно хранить только данные Git.
Протоколы
Git умеет работать с четырьмя сетевыми протоколами для передачи данных: локальный, HTTP, Secure Shell (SSH) и Git. В этой части мы обсудим каждый из них и в каких случаях стоит или не стоит его использовать.
Локальный протокол
Базовым протоколом является Локальный протокол, для которого удалённый репозиторий — это другой каталог на диске. Наиболее часто он используется, если все члены команды имеют доступ к общей файловой системе, например к NFS, или, что менее вероятно, когда все работают на одном компьютере. Последний вариант не идеален, поскольку все копии вашего репозитория находятся на одном компьютере, что резко увеличивает вероятность потерять всё.
Если у вас смонтирована общая файловая система, вы можете клонировать, отправлять и получать изменения из локального репозитория. Чтобы клонировать такой репозиторий или добавить его в качестве удалённого в существующий проект, используйте путь к репозиторию в качестве URL. Например, для клонирования локального репозитория вы можете выполнить что-то вроде этого:
Чтобы добавить локальный репозиторий в существующий проект, вы можете воспользоваться командой:
Теперь вы можете отправлять и получать изменения из этого репозитория так, как вы это делали по сети.
Достоинства
Также это хорошая возможность быстро получить наработки из чьего-то рабочего репозитория. Если вы и ваш коллега работаете над одним и тем же проектом, и он хочет, чтобы вы что-то проверили, то запуск команды вроде git pull /home/john/project зачастую проще, чем отправлять и забирать с удалённого сервера.
Недостатки
Недостаток этого метода в том, что общий доступ обычно сложнее настроить и получить из разных мест, чем простой сетевой доступ. Если вы хотите отправлять со своего ноутбука находясь дома, вы должны смонтировать удалённый диск, что может оказаться сложнее и медленнее, чем доступ по сети.
Также важно упомянуть, что не всегда использование общей точки монтирования является быстрейшим вариантом. Локальный репозиторий быстр, только если вы имеете быстрый доступ к данным. Репозиторий на NFS часто медленнее, чем репозиторий через SSH на том же сервере, позволяющий Git использовать на полную локальные диски на каждой системе.
Наконец, этот протокол не защищает репозиторий от случайного повреждения. Все пользователи имеют доступ к «удалённому» каталогу и ничего не мешает изменению или удалению внутренних файлов Git и, как следствие, повреждению репозитория.
Протоколы HTTP
Git может работать через HTTP в двух различных режимах. До версии Git 1.6.6 был только один режим, очень простой и предназначенный только для чтения. В версии 1.6.6 появился новый, более умный режим, позволяющий Git более интеллектуально определять необходимость передачи данных, наподобие того, как это происходит при использовании SSH. В последние годы новый протокол стал очень популярен, так как он проще для пользователя и более эффективен. Новая версия часто называется Умным (Smart) HTTP, а старая Тупым (Dumb) HTTP. Сначала мы рассмотрим Умный протокол.
Умный HTTP
«Умный» протокол HTTP работает схожим с SSH или Git-протоколами образом, но поверх стандартных HTTP/S портов и может использовать различные механизмы аутентификации HTTP, это часто проще для пользователя, чем что-то вроде SSH, так как можно использовать аутентификацию по логину/паролю вместо установки SSH-ключей.
На самом деле для сервисов вроде GitHub, адрес URL, который вы используете для просмотра репозитория в браузере (например, https://github.com/schacon/simplegit), можно использовать для клонирования или, если у вас есть доступ, для отправки изменений.
Тупой HTTP
Чаще всего вы будете использовать Умный 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, которые вы можете использовать для упрощения процесса. В разделе Хранилище учётных данных главы 7 рассказывается как настроить безопасное кэширование пароля в вашей системе.
Протокол SSH
Часто используемый транспортный протокол для самостоятельного хостинга Git — это SSH. Причина этого в том, что доступ по SSH уже есть на многих серверах, а если его нет, то его очень легко настроить. К тому же, SSH — протокол с аутентификацией, и его благодаря распространённости обычно легко настроить и использовать.
Чтобы клонировать Git-репозиторий по SSH, вы можете указать префикс ssh:// в URL, например:
Или можно использовать для протокола SSH краткий синтаксис наподобие scp:
Также вы можете не указывать имя пользователя, Git будет использовать то, под которым вы вошли в систему.
Достоинства
SSH имеет множество достоинств. Во-первых, SSH достаточно легко настроить — демоны SSH распространены, многие системные администраторы имеют опыт работы с ними и во многих дистрибутивах они предустановлены или есть утилиты для управления ими. Далее, доступ по SSH безопасен — данные передаются зашифрованными по авторизованным каналам. Наконец, так же как и протоколы HTTP/S, Git и локальный протокол, SSH эффективен благодаря максимальному сжатию данных перед передачей.
Недостатки
Недостаток SSH в том, что, используя его, вы не можете обеспечить анонимный доступ к репозиторию. Клиенты должны иметь доступ к машине по SSH, даже для работы в режиме только на чтение, что делает SSH неподходящим для проектов с открытым исходным кодом. Если вы используете Git только внутри корпоративной сети, то, возможно, SSH — единственный протокол, с которым вам придётся иметь дело. Если же вам нужен анонимный доступ на чтение для своих проектов, придётся настроить SSH для себя, чтобы выкладывать изменения, и что-нибудь другое для других, для скачивания.
Git-протокол
Достоинства
Git-протокол ― часто самый быстрый из доступных протоколов. Если у вас проект с публичным доступом и большой трафик, или у вас очень большой проект, для которого не требуется аутентификация пользователей для чтения, вам стоит настроить демон Git для вашего проекта. Он использует тот же механизм передачи данных, что и протокол SSH, но без дополнительных затрат на шифрование и аутентификацию.
Недостатки
Недостатком Git-протокола является отсутствие аутентификации. Поэтому обычно не следует использовать этот протокол как единственный способ доступа к вашему проекту. Обычно он используется в паре с SSH или HTTPS для нескольких разработчиков, имеющих доступ на запись, тогда как все остальные используют git:// с доступом только на чтение. Кроме того, это, вероятно, самый сложный для настройки протокол. Вы должны запустить отдельный демон, для чего необходимо дополнительно настраивать xinetd или systemd или им подобные, что не всегда легко сделать. Также необходимо, чтобы сетевой экран позволял доступ на порт 9418, который не относится к стандартным портам, всегда разрешённым в корпоративных брандмауэрах. За сетевыми экранами крупных корпораций этот неизвестный порт часто заблокирован.