Git
Chapters ▾ 2nd Edition

4.1 Git на сервері - Протоколи

Наразі, ви маєте бути в змозі виконувати більшість повсякденних задач, які вам зустрінуться при використанні Git. Втім, щоб мати можливість співпрацювати за допомогою Git, вам треба мати віддалене сховище Git. Хоч ви й можете викладати та забирати зміни зі сховищ кожної людини, це не рекомендується, адже так дуже легко заплутатися в тому, хто що робить, якщо не бути дуже обережним. До того ж, якщо ви бажаєте, щоб ваші колеги мали доступ до сховища навіть коли ваш комп’ютер поза мережею, мати більш надійне спільне сховище зазвичай розумно. Отже, зазвичай для співпраці з ким-небудь налаштовують проміжне сховище, до якого ви обидва маєте доступ, та викладаєте до і забираєте з нього.

Запустити Git сервер доволі просто.

Спершу вам треба обрати протокол, яким ви бажаєте щоб ваш сервер спілкувався. У першій секції цього розділу ми розповімо про доступні протоколи, переваги та недоліки кожного. Наступна секція пояснить деякі типові схеми використання цих протоколів та як змусити ваш сервер з ними працювати. В останній, ми поговоримо про деякі опції хостингу, якщо ви не проти зберігати ваш код на чужому сервері, та не бажаєте мати клопіт зі встановленням та підтримкою вашого власного серверу.

Якщо вас не цікавить запуск власного серверу, ви можете відразу перейти до останньої секції розділу, щоб побачити деякі варіанти налаштування хостингу та переходити до наступного розділу, де ми розглянемо різноманітні деталі роботи в середовищі розподіленої системи контролю коду.

Віддалене сховище зазвичай чисте сховище — сховище Git, що не має робочої теки. Адже сховище використовується тільки як місце для співпраці, нема підстав мати копію знімку на диску. Там просто дані Git. Найпростішими словами, чисте сховище містить тільки вміст теки .git вашого проекту та більше нічого.

Протоколи

Git може використовувати чотири різні протоколи для передачі даних: Локальний, HTTP, Secure Shell (SSH) та Git. Тут ми розглянемо що вони таке та у яких обставинах ви бажаєте (чи не бажаєте) їх використовувати.

Локальний протокол

Локальний протокол найпростіший, він потребує щоб віддалене сховище було в іншій теці на тій самій машині. Він часто використовується, якщо всі з вашої команди мають доступ до розподіленої файлової системи на кшталт NFS , чи в менш імовірному випадку, що всі заходять на один комп’ютер. Останній варіант далекий від ідеалу, адже усі копії вашого сховища перебувають на одному комп’ютері, що підвищує ймовірність катастрофічної втрати.

Якщо у вас спільна файлова система, то ви можете клонувати, викладати до, та забирати з локального файлового сховища. Щоб зробити клон такого сховища чи додати як віддалене сховище до існуючого проекту, достатньо використати шлях до сховища в якості URL. Наприклад, щоб зробити клон локального сховища, ви можете виконати щось таке:

$ git clone /srv/git/project.git

Чи зробити так:

$ git clone file:///srv/git/project.git

Git діє трошки по іншому, якщо ви явно задаєте file:// на початку URL. Якщо ви вкажете тільки шлях, Git спробує використати тверде посилання (hardlink), або просто скопіює теку, якщо потрібно. Якщо ви вкажете file://, Git запустить процеси, що він зазвичай використовує для передачі даних через мережу, що зазвичай є набагато менш ефективним. Зазвичай префікс file:// використовують, якщо бажають отримати чисту копію сховища без зовнішніх посилань чи об’єктів — зазвичай після імпорту з іншої СКВ, чи чогось подібного (дивіться Git зсередини щодо завдань підтримки). Ми будемо користуватись звичайним шляхом, адже це майже завжди швидше.

Щоб додати локальне сховище до існуючого проекту під контролем Git, ви можете виконати щось таке:

$ git remote add local_proj /srv/git/project.git

Після цього ви можете викладати до та забирати з цього віддаленого сховища за допомогою нової назви віддаленого сховища local_proj, ніби ви робите це через мережу.

Переваги

Перевага локальних сховищ в тому, що вони прості та використовують існуючи права доступу до файлів та доступу до мережі. Якщо у вас вже є спільна файлова система, до якої має доступ уся ваша команда, налаштувати сховище дуже просто. Ви кладете чисту копію свого сховища в якесь місце, до якого всі мають доступ, та налаштовуєте права читання/запису, як і для будь-якої іншої спільної теки. Ми розглянемо як експортувати чисту копію сховища для цього в Отримання Git на сервері.

Це також гарний варіант, щоб швидко взяти працю з іншого робочого сховища. Якщо ваш колега працює з вами над одним проектом та ви бажаєте щось перевірити, виконати команду схожу на git pull /home/taras/project часто легше, ніж щоб вони викладали до віддаленого серверу, а ви з нього потім отримували зміни.

Недоліки

Головний недолік цього методу в тому, що налаштувати спільний доступ з декількох вузлів зазвичай складніше, ніж простий мережевий доступ. Якщо ви бажаєте викладати з вашого ноутбуку, коли ви вдома, ви маєте примаунити віддалений диск, що може бути складно та повільно порівняно зі основаним на мережі доступом.

Важливо зазначити, що це не обов’язково найшвидша опція, якщо ви використовуєте спільний диск якогось типу. Локальне сховище швидке тільки якщо у вас є швидкий доступ до даних. Сховище на NFS зазвичай повільніше, ніж сховище через SSH на тому ж сервері, що дозволяє Git працювати з локальними дисками обох систем.

Нарешті, цей протокол не захищає схвовище від випадкових пошкоджень. Кожен користувач має повний доступ до “віддаленої” теки, і ніщо не заважає їм змінити чи вилучити внутрішні файли Git і зіпсувати сховище.

Протоколи HTTP

Git може спілкуватись через HTTP у двох режимах. До версії 1.6.6 у Git був тільки один метод, що був дуже простим та зазвичай тільки для читання. У версії 1.6.6 та новіших, був доданий кмітливіший протокол, що включає можливість Git проводити розумну передачу даних, схожу на те, як він працює через SSH. В останні декілька років, цей новий протокол HTTP став дуже розповсюдженим, адже він простіший для користувача та кмітливиший щодо методу передачі. Новішу версію часто називають розумним HTTP протоколом, а старішу — тупим HTTP Ми спочатку поговоримо про Розумний HTTP протокол.

Розумний HTTP

Розумний HTTP діє дуже схоже на те, як працює SSH чи Git протоколи, проте працює через звичайні HTTPS порти та може використовувати різноманітні механізми авторизації HTTP, отже часто цей метод простіший для користувачів, ніж SSH, адже можна використовувати логін/пароль авторизації замість налаштування ключів SSH.

Розумний HTTP напевно став найпопулярнішим методом використання Git, адже його можна налаштувати як для анонімної праці, як протокол git://, та до нього можна викладати з авторизацією та шифрування, як і з SSH протоколом. Замість налаштування різних URLів для цих речей, ви можете використовувати для них однин URL. Якщо ви спробуєте викласти, а сховище вимагає авторизації (як зазвичай і повинно бути), сервер запитає логін та пароль. Те ж саме стосується і доступу на читання.

Насправді, для таких сервісів як GitHub, URL, що ви використовуєте для перегляду сховища в мережі (наприклад, https://github.com/schacon/simplegit) збігається з URLом, що ви можете використовувати для клонування, та, якщо у вас є доступ, викладати до нього.

Тупий HTTP

Якщо сервер не відповідає на розумний сервіс HTTP, клієнт Git спробує відкотитись до простішого тупого HTTP протоколу. Тупий протокол очікує, що чисте сховище Git буде обслуговуватись як звичайні файли на веб сервері. Краса тупого протоколу HTTP в простоті його налаштування. Вам треба просто викласти чисте сховище Git під коренем документів HTTP та встановити потрібний гачок (хук, hook) post-update, ось і все (Дивіться Гаки (hooks) Git). Після цього, усі, в кого є доступ до веб серверу, на котрий ви скопіювали своє сховище, можуть зробити його клон. Щоб дати доступ на читання вашого сховища через 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), щоб HTTP діставання та клонування працювало правильно. Ця команда виконується, коли ви викладаєте до цього сховища (можливо через SSH). Тоді інші люде люди зможуть клонувати за допомогою

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

Саме у цьому випадку, ми використовуємо шлях /var/www/htdocs, що є звичайним для серверів Apache, проте ви можете використовувати статичний веб сервер — просто покладіть чисте сховище до нього. Дані Git видаються як прості статичні файли (дивіться Git зсередини для докладнішої розповіді про те, як саме вони видаються)

Зазвичай ви або виберете Розумний HTTP сервер з можливістю читання/запису, або просто організуєте доступ до файлів з правом тільки на читання за допомогою Тупої опції. Дуже рідко ці два варіанти суміщають.

Переваги

Ми зосередимось на перевагах Розумної версії HTTP протоколу.

Простота використання одного URL для всіх типів доступу та те, що сервер потребує авторизації тільки коли потрібно робить користування сервером дуже простим для користувача. Можливість авторизації з логіном та паролем також велика перевага над SSH, оскільки користувачі не мають генерувати SSH ключі локально та завантажувати публічний ключ до серверу до того, як вони зможуть взаємодіяти з ним. Для менш досвідчених користувачів, чи користувачів, що використовують системи де SSH менш розповсюджений, це може стати головною перевагою в зручності. Це також дуже швидкий та ефективний протокол, схожий на SSH.

Ви також можете надавати доступ до вашого сховища тільки на читання через HTTPS, тобто ви можете шифрувати зміст передачі. Чи ви можете навіть змусити клієнтів використовувати специфічні підписані SSL сертифікати.

Ще одна гарна властивість HTTPS в тому, що це такі розповсюджені протоколи, що корпоративні мережеві екрани зазвичай налаштовані дозволяти передачу через ці порти.

Недоліки

Git через HTTPS може бути трохи складнішим у порівнянні з SSH на деяких серверах. Окрім цього, інші протоколи мають дуже мало переваг над розумним HTTP для надання доступу до даних Git.

Якщо ви використовуєте HTTP для авторизованого викладання, посвідчення вашого акаунту іноді може буди складнішим, ніж за допомогою ключів через SSH. Втім існує декілька утиліт для кешування даних входу, наприклад Keychaing access на macOS та Credential Manager на Windows, що дозволяє уникнути цієї проблеми. Прочитайте Збереження посвідчення (credential) щоб дізнатись як налаштувати безпечне кешування HTTP паролю на вашій системі.

Протокол SSH

SSh доволі поширений протокол передачі для Git при самостійному хостінгу. Причина в тому, що доступ SSH до серверу в більшості випадків вже налаштовано — а якщо ні, це дуже легко зробити. Крім того, мережевий протокол SSH має авторизацію і, оскільки він повсюдний, зазвичай його легко налаштовувати та використовувати.

Щоб зробити клон Git сховища через SSH, ви можете задати ssh:// URL ось так:

$ git clone ssh://[user@]server/project.git

Чи ви можете використати скорочений синтаксис (подібний до scp) для SSH протоколу:

$ git clone [user@]server:project.git

Ви також можете не задавати користувача, тоді Git використає поточного користувача. В обох наведених вище прикладах Git використає поточного системного користувача, якщо не задати опціонального імені користувача.

Переваги

Є багато переваг використання SSH. По-перше, SSH відносно легко налаштувати — демони SSH є повсюди, багато мережевих адміністраторів мають з ними досвід, та багато дистрибутивів поставляються з ними та навіть мають утиліти щоб ними керувати. Далі, доступ через SSH безпечний — усі дані передачі зашифровані та авторизовані. Наостанок, як і HTTPS, Git та Локальний протоколи, SSH є ефективним, робить дані якомога компактними до відправки.

Недоліки

Недоліком SSH є те, що він не підтримує анонімний доступ до вашого сховища. Якщо ви використовуєте SSH, користувачі зобов’язані мати SSH доступ до вашої, навіть тільки для читання, через що SSH не є продуктивним для проектів з відкритим кодом, у яких люди цілком можуть хотіти просто склонувати його, щоб ознайомитися з ним. Якщо ви використовуєте його тільки в межах вашої корпоративної мережі, SSH може бути єдиним протоколом, що вам потрібен. Якщо ви бажаєте дозволити анонімний доступ тільки для читання до ваших проектів та також бажаєте використовувати SSH, вам доведеться налаштувати SSH для надсилання змін, проте щось інше, щоб решта людей здобували зміни.

Протокол Git

Наступним є протокол Git. Це спеціальний демон, що входить до пакету Git. Він слухає на виділеному порту (9418), що надає сервіс схожий на SSH протокол, проте без жодної авторизації. Щоб надати доступ до сховища за допомогою протоколу Git, ви маєте створити файл git-daemon-export-ok — демон відмовляється роздавати сховище без цього файлу — проте ніяких інших засобів безпеки не надає. Або сховище Git доступно всім, або нікому. Це означає, що зазвичай через цей протокол забороняється викладання. Ви можете ввімкнути доступ до викладання. Проте за відсутності авторизації, якщо ви це зробите, будь-хто в мережі, хто знайде це сховище, зможе до нього викладати. Достатньо сказати, що таке має сенс доволі рідко.

Переваги

Git протокол часто є найшвидшим доступним протоколом передачі в мережі. Якщо ви передаєте великі обсяги даних для відкритого проекту чи роздаєте дуже великий проект, що не вимагає авторизації для читання, вірогідно ви забажаєте налаштувати Git демон для обслуговування вашого проекту. Він використовує той самий механізм передачі даних, що й SSH протокол, проте без додаткових витрат на шифрування та авторизацію.

Недоліки

Головним недоліком протоколу Git є відсутність авторизації. Зазвичай небажано щоб протокол Git був єдиним протоколом доступу до вашого проекту. Зазвичай, його використовують у парі з SSH чи HTTPS доступом для декількох розробників, що мають право викладати (писати), а усі інші використовують git:// для читання. Також це мабуть найскладніший для налаштування протокол. Для нього має працювати власний демон, що вимагає щось подібне до конфігурації xinetd, що не завжди схоже на прогулянку по парку. Також це вимагає щоб мережеві екрани дозволяли доступ до порту 9418, що не є стандартним дозволеним корпоративним портом. За великими корпоративними мережевими екранами, цей незрозумілий порт зазвичай є заблокованим.