4.1 Git na serveru - Protokoly

Výhoda souborových repozitářů spočívá v tom, že jsou jednoduché a používají existující oprávnění k souborům a pro přístup k síti. Pokud už máte k dispozici sdílený systém souborů, k němuž má přístup celý váš tým, je nastavení repozitáře velice jednoduché. Kopii holého repozitáře umístíte někam, kam mají všichni sdílený přístup, a nastavíte oprávnění ke čtení/zápisu stejně jako u jakéhokoli jiného sdíleného adresáře. O exportu kopie holého repozitáře pro tento účel se více dočtete v části Zprovoznění Gitu na serveru.

Je to taky šikovná možnost rychlého získání práce z pracovního repozitáře někoho jiného. Pokud vy a váš kolega pracujete na společném projektu a máte z něj něco přetáhnout, pak provedení příkazu jako git pull /home/john/project je často jednodušší, než aby jej on nejdříve odeslal (push) na vzdálený server a teprve z něho byste práci stahovali.

Nevýhodou této metody je, že nastavení vzdáleného přístupu a dosažitelnosti z více míst je obtížnější než obyčejný síťový přístup. Pokud budete chtít odeslat data z notebooku doma, budete muset připojit vzdálený disk, což může být ve srovnání s přístupem přes lokální síť složité a pomalé.

Upozorněme na to, že v případě použití sdíleného přístupu určitého druhu^[13], nemusí být tato možnost vždy nutně nejrychlejší. Lokální repozitář je rychlý pouze v případě, že máte rychlý přístup k datům. Repozitář na NFS je často pomalejší než stejný repozitář nad SSH na tomtéž serveru, který ve všech systémech umožňuje spustit Git z lokálních disků.

Na závěr uveďme, že tento protokol nechrání repozitář vůči nechtěnému poškození. K „vzdálenému“ adresáři má každý uživatel plný přístup přes shell a nic mu nebrání v tom, aby změnil nebo odstranil soubory, které Git vnitřně používá, a repozitář tím porušil.

„Chytrý“ HTTP protokol pracuje velmi podobně jako protokol SSH nebo protokol Git, ale využívá standardní HTTP/S porty a může použít různé autentizační mechanismy protokolu HTTP. To znamená, že je s uživatelského hlediska často jednodušší než například SSH, protože místo nastavování SSH klíčů můžete použít základní autentizace využívající uživatelské jméno a heslo.

Při používání Gitu se v současnosti stal pravděpodobně nejoblíbenějším, protože u něj lze nastavit jak anonymní přístup (jako u protokolu git://), tak i odesílání podmíněné autentizací a využívající šifrování (jako u protokolu SSH). Pro uvedené účely nemusíme nastavovat dvě různá URL — stačí použít jedno URL pro oba typy přístupu. Pokud se do repozitáře pokusíme něco odeslat (push) a repozitář vyžaduje autentizaci (což by obvykle měl), může server zobrazit výzvu k zadání uživatelského jména a hesla. Totéž platí pro přístup pro čtení.

U služeb jako GitHub je ve skutečnosti URL, které používáte pro on-line přístup k repozitáři (například https://github.com/schacon/simplegit), to stejné URL, které můžete použít pro klonování a — pokud máte přístupová práva pro zápis — také pro odesílání.

Pokud server nepodporuje chytrou gitovou službu nad HTTP, pokusí se gitový klient vrátit k jednoduššímu „hloupému“ HTTP protokolu. Hloupý protokol předpokládá, že se bude holý gitový repozitář obsluhovat ze strany webového serveru stejně, jako běžné soubory. Krása hloupého HTTP protokolu spočívá v jednoduchosti jeho nastavení. V podstatě jediné, co musíte udělat, je umístit holý gitový repozitář pod kořenový adresář s HTTP dokumenty a nastavit příslušný zásuvný modul post-update (viz kapitola Git Hooks). Od tohoto okamžiku může každý, kdo má přístup k webovému serveru, kam jste repozitář uložili, tento repozitář naklonovat. Chcete-li u svého repozitáře nastavit oprávnění pro čtení pomocí protokolu HTTP, proveďte následující:

To je vše. Zásuvný modul post-update, který je standardní součástí systému Git, spustí příslušný příkaz (git update-server-info), který zajistí správné vyzvedávání (fetch) a klonování přes protokol HTTP. Tento příkaz se spustí, když do tohoto repozitáře odesíláte data (možná přes protokol SSH). Poté mohou ostatní klonovat třeba takto:

V tomto konkrétním případě používáme cestu /var/www/htdocs, která se obvykle nastavuje pro Apache, ale použít lze v podstatě jakýkoliv statický webový server — stačí uložit holý repozitář do dané cesty. Data repozitáře Git jsou obsluhována jako obyčejné statické soubory (podrobnosti o přesném způsobu obsluhy naleznete v kapitole Git Internals).

Obecně se dá říct, že si buď vyberete „chytrý“ HTTP server umožňující čtení i zápis, nebo soubory zpřístupníte jen pro čtení „hloupým“ protokolem. Současné použití obou služeb je neobvyklé.

Zaměříme se na výhody „chytré“ verze HTTP protokolu.

Jednoduchost spočívající v používání jediného URL pro všechny typy přístupu a to, že se server vyptává, jen když požaduje autentizaci, to vše koncovému uživateli věci velmi usnadňuje. Možnost autentizace uživatelským jménem a heslem představuje vůči SSH také velkou výhodu, protože si uživatel nemusí na svém počítači generovat SSH klíče a nahrávat svůj veřejný klíč na server, aby se serverem vůbec mohl pracovat. Pro méně zdatné uživatele nebo pro uživatele na systémech, kde SSH není tak běžné, to představuje z hlediska použitelnosti velkou výhodu. Navíc jde o velmi rychlý a efektivní protokol (podobně jako protokol SSH).

Své repozitáře můžete zpřístupnit ke čtení i prostřednictvím protokolu HTTPS, což znamená, že se přenášený obsah šifruje. Nebo můžete zajít ještě dál a vyžadovat, aby klienti používali konkrétní podepsané SSL certifikáty.

Další výhodou je, že HTTP/S jsou tak často používané protokoly, že už jsou firemní firewally často nastaveny tak, aby byl provoz přes jejich porty povolen.

Na některých serverech může být (ve srovnání s protokolem SSH) nastavení protokolu „Git přes HTTP/S“ trochu složitější. Ale jinak mají ostatní protokoly pro obsluhu Gitu vůči „chytrému“ HTTP protokolu jen velmi malé výhody.

Pokud používáte HTTP pro autentizované odesílání, pak může být nastavení osobních údajů někdy komplikovanější než používání klíčů přes SSH. Ale můžete využít několika nástrojů pro uložení osobních údajů (credential caching tools), včetně „Keychain Access“ pro OSX a „Správce pověření“ pod Windows, čímž se to velmi usnadní. O tom, jak na vašem systému nastavit bezpečné uložení hesla pro HTTP, se dočtete v podkapitole Credential Storage.

Používání protokolu SSH přináší mnoho výhod. Zaprvé se protokol SSH snadno nastavuje — SSH démoni jsou zcela běžní, správci sítě si s nimi mají zkušenosti a mnoho distribucí OS je má ve výchozí instalaci nebo poskytuje nástroje pro jejich správu. Za další je přístup přes protokol SSH bezpečný — veškerý přenos dat je šifrovaný a autentizovaný. A nakonec — stejně jako je tomu u HTTP/S, u protokolu Git a u lokálních protokolů — SSH je efektivní, protože data před přenosem upravuje do co nejkompaktnější podoby.

Nevýhodou protokolu SSH je, že neumožňuje anonymní přístup do repozitáře. Ostatní musí mít k vašemu počítači přes SSH zřízen přístup, byť třeba jen ke čtení. Proto se přístup přes SSH nehodí pro open-source projekty. Pokud jej používáte jen v rámci firemní sítě, může se SSH stát jediným protokolem, kterým se budete muset zabývat. Pokud budete chtít pro vaše projekty zřídit anonymní přístup pro čtení a současně budete chtít používat SSH, budete muset SSH nastavit jinak pro sebe (pro odesílání; push) a jinak pro ostatní (pro vyzvedávání; fetch).

Protokol Git je často ze všech dostupných síťových přenosových protokolů nejrychlejší. Potřebujete-li obsloužit frekventovaný provoz u veřejného projektu nebo obsluhujete velmi velký projekt, u kterého se pro čtení nevyžaduje autentizace uživatele, bude se vám k obsluze asi nejvíc hodit právě démon Git. Používá stejný mechanismus přenosu dat jako protokol SSH, na rozdíl od něj ale není zpomalován šifrováním a ověřováním identity (autentizací).

Nevýhodou protokolu Git je, že neprovádí autentizaci. Většinou není žádoucí, aby protokol Git představoval jedinou možnost přístupu k vašemu projektu. Většinou jej doplníte o přístup přes SSH nebo přes HTTPS pro pár vývojářů, kteří budou mít právo odesílat data (zápis; push). A všichni ostatní budou používat git:// pro přístup pouze ke čtení. Pravděpodobně se také jedná o protokol s nejobtížnějším nastavením. Běží pro něj vlastní démon, který vyžaduje konfiguraci xinetd nebo podobnou, což vždy není procházka růžovou zahradou. Vyžaduje rovněž povolení přístupu k portu 9418 přes firewall. Tento port nepatří mezi standardní porty, které by firemní firewally vždy povolovaly. Velkými podnikovými firewally je tento obskurní port většinou blokován.