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

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

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

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

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

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

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

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

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

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

Ось і все. Гачок post-update входить у стандартну поставку Git, та виконує відповідні команди (git update-server-info), щоб HTTP діставання та клонування працювало правильно. Ця команда виконується, коли ви викладаєте до цього сховища (можливо через SSH). Тоді інші люде люди зможуть клонувати за допомогою

Саме у цьому випадку, ми використовуємо шлях /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 відносно легко налаштувати — демони SSH є повсюди, багато мережевих адміністраторів мають з ними досвід, та багато дистрибутивів поставляються з ними та навіть мають утиліти щоб ними керувати. Далі, доступ через SSH безпечний — усі дані передачі зашифровані та авторизовані. Наостанок, як і HTTPS, Git та Локальний протоколи, SSH є ефективним, робить дані якомога компактними до відправки.

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

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

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