Git
Chapters ▾ 2nd Edition

4.1 Git na serveru - Protokoly

V tomto okamžiku už byste měli zvládat většinu každodenních úkonů, pro které budete Git používat. Ale abyste mohli pomocí Gitu spolupracovat s ostatními, budete potřebovat vzdálený gitový repozitář. Technicky vzato sice můžete odesílat a stahovat změny z repozitářů jednotlivých spolupracovníků, ale tento přístup se nedoporučuje, protože si při troše neopatrnosti můžete velmi snadno poplést, kdo na čem pracuje. Navíc chcete, aby měli vaši spolupracovníci do repozitáře přístup, i když je váš počítač vypnutý nebo odpojený. Často bývá spolehlivější, když existuje společný repozitář. Proto se pro spolupráci s ostatními doporučuje zřídit repozitář, ke kterému mají zúčastnění přístup pro odesílání (push) i pro stahování (pull).

Zprovoznění gitového serveru je celkem jednoduché. Nejprve určíte, jakými protokoly má váš server komunikovat. První část této kapitoly se bude věnovat dostupným protokolům a kladům a záporům každého z nich. V dalších částech vysvětlíme některé typické konfigurace, které těchto protokolů využívají, a jak s nimi uvést server do provozu. Nakonec se podíváme na několik možností hostování — pokud vám nevadí, že máte kód umístěný na cizím serveru, a nechcete se otravovat s nastavováním a údržbou svého vlastního serveru.

Pokud víte, že nebudete chtít spravovat vlastní server, můžete přeskočit rovnou na poslední část této kapitoly a podívat se na možnosti nastavení hostovaného účtu. Pak přejděte na následující kapitolu, v níž se dočtete o detailech a záludnostech při práci v prostředí s distribuovanou správou zdrojového kódu.

Vzdáleným repozitářem je obvykle holý repozitář (bare repository), tj. gitový repozitář bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou zde uložena pouze data pro Git. Když to zjednodušíme, holý repozitář je obsah adresáře .git vašeho projektu a nic víc.

Protokoly

Git může k přenosu dat používat čtyři hlavní protokoly: lokální, HTTP, Secure Shell (SSH) a Git. V této části si probereme, co jsou zač a za jakých základních okolností je budete (nebo nebudete) chtít použít.

Lokální protokol

Nejzákladnějším z nich je lokální protokol, kdy je vzdálený repozitář uložen v jiném adresáři na disku. Často se využívá v případech, kdy mají všichni z vašeho týmu přístup k sdílenému souborovému systému (například přes NFS), nebo v méně pravděpodobném případě, kdy se všichni přihlašují na stejný počítač. Druhá varianta není právě ideální, protože všechny instance repozitáře s kódem jsou umístěny na stejném počítači, čímž se zvyšuje riziko katastrofické ztráty dat.

Máte-li připojený sdílený systém souborů, můžete klonovat, odesílat a stahovat z lokálního souborového repozitáře. Při klonování takového repozitáře, nebo při jeho přidávání jako vzdáleného repozitáře existujícího projektu, se v roli URL používá cesta k repozitáři. Naklonování lokálního repozitáře můžete provést například spuštěním něčeho takového:

$ git clone /opt/git/project.git

Nebo můžete provést následující:

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

Pokud na začátek URL explicitně uvedete file://, pracuje Git trochu jinak. Pokud uvedete pouze cestu, pokouší se Git použít pevné odkazy (hardlink), nebo přímo kopíruje potřebné soubory. Pokud zadáte výraz file://, Git spustí procesy, které běžně používá k přenosu dat po síti, což je obecně mnohem méně efektivní metoda přenosu dat. Hlavním důvodem, proč zadat předponu file:// je to, že tak získáte čistou kopii repozitáře bez nepotřebných referencí a objektů, například po importu z jiného verzovacího systému a podobně (viz popis úkonů správy v kapitole Git Internals). My zde budeme používat normální cestu, protože je to téměř vždy rychlejší.

K přidání lokálního repozitáře do existujícího gitového projektu můžete zadat něco takového:

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

Poté můžete do vzdáleného repozitáře data odesílat (push) a stahovat je z něj (pull), jako byste tak činili prostřednictvím sítě.

Výhody

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ýhody

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.

Protokoly HTTP

Git umí pře HTTP komunikovat ve dvou různých režimech. Před verzí Git 1.6.6 existoval jediný způsob, který byl velmi jednoduchý a obecně umožňoval jen čtení. Ve verzi 1.6.6 byl zaveden nový, chytřejší protokol, který Gitu umožnil inteligentní dohodu na tom, jak se budou data přenášet — podobným způsobem, jak se to dělá přes SSH. V posledních letech se tento nový HTTP protokol stal velmi oblíbeným, protože je uživatelsky jednodušší a používá chytřejší způsob komunikace. Nová verze se často označuje jako „chytrý“ HTTP protokol a starší jako „hloupý“ HTTP. Nejdříve se budeme věnovat „chytrému“ HTTP protokolu.

Chytrý HTTP

„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í.

Hloupý HTTP

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í:

$ 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

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:

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

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é.

Výhody

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.

Nevýhody

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.

Protokol SSH

Při používání Gitu ve vlastním prostředí se běžně používá protokol SSH. Je to z toho důvodu, že SSH přístup k serverům je na většině míst už nastaven, a pokud ne, není těžké ho nastavit. SSH je navíc síťovým protokolem s autentizací. A protože je všudypřítomný, je jeho nastavení a používání většinou snadné.

Chcete-li gitový repozitář naklonovat s přes SSH, můžete zadat URL začínající ssh://, například:

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

Nebo můžete pro SSH protokol použít kratší syntaxi jako u scp:

$ git clone user@server:project.git

Nemusíte ani zadávat uživatele. Git pak použije uživatele, který je právě přihlášen.

Výhody

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ýhody

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

Dalším v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakékoliv autentizace. Chcete-li, aby byl repozitář zpřístupněn protokolem Git, musíte vytvořit soubor git-daemon-export-ok. Bez tohoto souboru nebude repozitář démonem zpřístupněn. Žádné jiné zabezpečení ale k dispozici není. Gitový repozitář je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze zapnout, ale protože nepodporuje autentizaci, pak pokud zapnete možnost odesílání, může do vašeho projektu odesílat data (push) každý, kdo na internetu nalezne URL vašeho projektu. Je jasné, že to většinou nechcete.

Výhody

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ýhody

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.