Git
Chapters ▾ 2nd Edition

4.1 Git on the Server - Protokoli

Sada bi trebalo da možete da uradite većinu svakodnevnih zadataka koristeći Git. Međutim, da biste imali bilo kakav vid kolaboracije u Gitu, neophodan je udaljeni Git repozitorijum. Mada tehnički možete da gurate promene i da vučete promene sa repozitorijuma individualnih ljudi, takav pristup se ne preporučuje jer može vrlo lako doći do zabune ako ne budete pažljivi. Štaviše, želećete da vaši kolaboratori mogu da pristupe repozitorijumu čak i kada je vaš računar oflajn — imati pouzdaniji zajednički repozitorijum je često korisno. Zato, bolja metoda za kolaboraciju sa nekim je postavljanje među-repozitorijuma kojem svi imaju pristup, i guranje i povlačenje s njega.

Rukovoditi Git serverom je dosta jednostavno. Prvo, izaberete kojim protokolima želite da vaš server komunicira. Prvi odeljak ovog poglavlja će pokriti neke dostupne protokole i izlistati prednosti i mane svakog od njih. Sledeći odeljci će objasniti neke tipične postavke koje koriste ove protokole i kako namestiti server koji će raditi sa njima. Za kraj, preći ćemo nekoliko opcija za hostovanje, ako vam ne smeta da hostujete svoj kod na tuđem serveru i ne želite da se mučite da postavite i održavate sopstveni server.

Ako vas ne zanima vođenje sopstvenog servera, možete da skočite na poslednju sekciju ovog poglavlja da pogledate neke opcije za podešavanje hostovanog naloga i onda da pređete na sledeće poglavlje, gde ćemo diskutovati o raznim ispravnim načinima za rad u distribuiranom okruženju za kontrolu izvornog koda.

Udaljeni repozitorijum je u opštem slučaju go repozitorijum — Git repozitorijum koji nema radni direktorijum. Pošto se repozitorijum koristi samo kao tačka za kolaboraciju, nema razloga da ima čekautovan snimak na disku; to su samo Git podaci. Najjednostavnije rečeno, go repozitorijum je sadržaj .git direktorijuma vašeg projekta i ništa drugo.

Protokoli

Git može da koristi četiri glavna protokola za transfer podataka: Local, HTTP, Secure Shell (SHH) i Git. Ovde ćemo prodiskutovati šta su oni i u kakvim biste okolnostima želeli (ili ne biste želeli) da ih korstite.

Lokalni protokol

Najosnovniji je Lokalni protokol, kod koga se udaljeni repozitorijum nalazi na drugom direktorijumu na disku. Ovo se često koristi ako svi u timu imaju pristup deljenom fajl sistemu kao što je NFS, ili u manje verovatnom slučaju ako se svi loguju na isti računar. Drugi slučaj ne bi bio idealan, jer bi se sve instance koda iz repozitorijuma nalazile na istom računaru, što bi učinilo katastrofalni gubitak verovatnijim.

Ako imate deljen mauntovan fajl sistem (shared mounted filesystem), onda možete da klonirate lokalni repozitorijum, da gurate na njega i da povlačite sa njega. Da klonirate ovakav repozitorijum ili da dodate jedan kao rimout postojećem objektu, koristite putanju do repozitorijuma kao URL. Na primer, da biste klonirali lokalni repozitorijum, pokrenite nešto ovako:

$ git clone /opt/git/project.git

Možete da uradite i ovo:

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

Git radi malo drugačije ako eksplicitno navedete file:// na početku URL-a. Ako specificirate samo putanju, Git pokušava da koristi hardlinkove ili da dirketno kopira fajlove koji su mu potrebni. Ako specificirate file://, Git pokreće proces koji obično koristi za transfer podataka preko mreže koji je generalno mnogo manje efikasna metoda za prenos podataka. Glavni razlog zbog koga biste možda želeli da specificirate prefiks file:// je ukoliko želite čistu kopiju repozitorijuma sa izbačenim stranim referencama i objektima — recimo posle importa sa drugog sistema za kontrolu verzije ili nešto slično (pogledajte Git iznutra za zadatake oko održavanja.) Ovde ćemo koristiti normalnu putanju jer je tako skoro uvek brže.

Da biste dodali lokalni repozitorijum u postojeći Git projekat, možete da pokrenete nešto ovako:

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

Onda možete da gurate na taj rimout i da povlačite sa njega kao što ste radili i preko mreže.

Prednosti

Prednosti repozitorujuma baziranih na fajlovima su to što su jednostavni i koriste postojeće dozvole nad fajlovima i pristup mreži. Ako već imate deljivi fajl sistem kome želite da ceo tim pristupa, podešavanje ovakvog repozitorijuma je veoma lako. Smestite golu kopiju repozitorijuma negde gde svi imaju deljivi pristup i podesite dozvole za čitanje i upis kao što biste kod bilo kod drugog deljivog direktorijuma. U Git on the Server ćemo diskutovati o tome kako da eksportujete gole kopije repozitorijuma za ovu namenu.

Ovo je takođe dobra opcija da brzo zgrabite rad sa nečijeg drugog radnog repozitorijuma. Ako vi i saradnik radite na istom projektu, i on ili ona želi da vam čekautuje nešto, pokretanje komande kao što je git pull /home/john/project je obično lakše nego da guraju podatke na udaljeni server a da ih vi povučete.

Mane

Mane ove metode su to što je kod deljivog pristupa generalno teže podesiti i pristupiti serveru sa razlilčitih lokacija nego kod osnovnog pristupa mreži. Ako želite da gurnete sa laptopa kada ste kući, morate da mauntujete udaljeni disk, što može da bude teško i sporo u poređenju sa pristupom preko mreže.

Važno je pomenuti da ovo nije uvek najbrža opcija ako koristite neki udeljeni maunt. Lokalni repozitorijum je brz samo ako imate brz pristup podacima. Repozitorijum na NFS-u je često sporiji nego repozitorijum preko SSH-a na istom serveru, što dopušta Gitu da umnoži lokalne diskove na svakom sistemu.

Konačno, ovaj protok ne štiti repozitorujum od slučajne štete. Svaki korisnik ima potpuni pristup preko šela "udaljenom" direktorijumu, i nema ništa što ga sprečava da promeni ili ukloni interne Git fajlove i time pokvari repozitorijum.

HTTP protokoli

Git može da komunicira preko HTTP-a u dva različita režima. Pre verzije Git 1.6.6, postojao je samo jedan način na koji se ovo moglo obaviti; bio je veoma jednostavan i u opštem slučaju je dozvoljavao samo čitanje. U verziji 1.6.6, predstavljen je novi i pametniji protokol koji je omogućio Gitu da na pametan način može da pregovara o razmeni podataka na sličan način na koji to radi SSH. U poslednjih nekoliko godina, ovaj novi HTTP protokol je postao veoma popularan zato što je jednostavniji za korisnike i pametniji o tome kako obavlja komunikaciju. Nova verzija se često naziva "Pametni" HTTP protokol, a stari način "Priglup" HTTP. Prvo ćemo pokriti novi, Pametni HTTP protokol.

Pametni HTTP

Pametni HTTP protokol radi slično kao SSH ili Git protokoli, s tim što se obavlja preko standardnih HTTP/S portova i može da koristi razne HTTP mehanizme za autentifikaciju, što znači da je nešto lakše što se korisnika tiče od nečeg kao što je SSH, obzirom na to da možete da kroistite, na primer, osnovnu autentifikaciju pomoću korisničkog imena i šifre umesto pomoću SSH ključeva.

Ovo je sada verovatno postao najpopularniji način za korišćenje Gita, pošto se može podesiti da pruža usluge i anonimno kao protokol git://, ali i pomoću autentifikacije i enkripcije kao SSH protokol. Umesto da podešavate različite URL-ove za ove stvari, sada možete da koristite samo jedan za oba. Ako probate da gurnete na repozitorijum koji zahteva autentifikaciju (što treba da bude slučaj), server će vam zatražiti korisničko ime i lozinku. Isto važi i za pristup čitanjem.

Zapravo, za servise kao što je GitHub, URL koji koristite da pogledate repozitorijum onjaln (na primer, “https://github.com/schacon/simplegit”) je isti URL koji možete da koristite za kloniranje, i, ako imate pristup, za guranje.

Priglup HTTP

Ako server nema podršku za rad sa Gitovom pametnom verzijom HTTP-a, Git klijent će probati da se poveže koristeći jednostavniji "priglupi" HTTP protokol. Priglup protokol očekuje da se goli Git repozitorijum servira kao obični fajlovi sa veb-servera. Lepota Priglupog HTTP protokola je jednostavnost njegovog podešavanja. U osnovi, sve što treba da uradite jeste da objavite goli Git repozitorijum pod korenom HTTP dokumenta i da podesite specifičan post-update huk, i gotovo je (pogledajte Git hukovi). Sada svako ko može da pristupi veb-serveru pod kojim ste stavili repozitorijum može i da klonira vaš repozitorijum. Da biste dozvolili čitanje repozitorijuma preko HTTP-a, uradite nešto slično sledećem:

$ 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 sve. Huk post-update koji dolazi uz Git po podrazumevanim podešavanjima pokreće odgovarajuću komandu (git update-sever-info) koja omogućuje da HTTP pribavljanje i kloniranje radi kako treba. Ova komanda se pokreće kada gurate na ovaj repozitorijum (na primer preko SSH-a); drugi ljudi onda mogu da kloniraju koristeću komandu nalik sledećoj.

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

U ovom slučaju, koristimo putanju /var/www/htdocs koja je česta u Apache podešavanjima, ali možete i da koristite bilo koji statički veb-server — samo stavite goli repozitorijum u njegovu potanju. Git podaci se serviraju kao obični statički fajlovi (pogledajte Git iznutra za detalje o tome kako se tačno obavlja serviranje).

U optem slučaju treba da napravite izbor između Pametnog HTTP servera koji nudi čitanje i upis ili da omogućite jednostavan pristup za čitanje preko Priglupog. Retko se mešaju ova dva servisa.

Prednosti

Koncentrisaćemo se na prednosti Pametne verzije HTTP protokola.

Činjenica da postoji jedinstveni URL za sve vrste pristupa i to što server od korisnika zahteva autentifikaciju samo kada je ona neophodna čini stvari mnogo jednostavnijim za krajnjeg korisnika. To što je moguća autentifikacija pomoću korisničkog imena i šifre je takođe velika prednost nad SSH-om, potšo korisnici ne moraju da generišu SSH ključeve lokalno i oglašavaju ih serveru pre nego što mogu da interaguju s njim. Za manje sofisticirane korisnike, ili za korisnike na sistemima gde SSH niej tako čest izbor komunikacije, ovo je velika prednost za upotrebljivost. Takođe je veoma brz i efikasan protokol, sličan SSH-u.

Sem toga, možete servirati repozitorijume za čitanje preko HTTPS-a, što znači da možete da enkriptujere sadržaj transfera; ili možete da idete do te mere da naterate klijente da koriste posebne potpisane SSL sertifikate.

Još jedna lepa stvar je to što su HTTP/S toliko često korišćeni protokoli da su korporativni fajervolovi često podešeni tako da dozvoljavaju prenos saobraćaja kroz njih.

Mane

Git preko HTTP/S-a ume da bude malo nezgodniji za pdoešavanje u poređenju sa SSH-om na nekim serverima. Sem tome, nema mnogo prednosti koje drugi protokoli nude spram Pametnog HTTP-a, kada je u pitanju Git.

Ako koristite HTTP za autentifikovano guranje, dostavljanje akreditiva je nekad komplikovanije nego korišćenje ključeva preko SSH-a. Ipak, postoji nekoliko alata za keširanje akdreditiva koje možete da koristiti, uključujući Keychain za OSX i Credential Manager za Vindouz, što će učiniti ovaj postupak prilično bezbolinim. Pročitajte Credential Storage da vidite kako da pdoesite sigurni HTTP sistem za keširanje na svom sistemu.

SSH Protokol

Čest protokol za prenos podataka koji se koristi kada sami obavljate hosting jeste SSH. Ovako je zato što je SSh pristup serverima već podešen na većini mesta — a ako nije, lako je podesiti ga. SSH je takođe autentifikovan mrežni protokol; zato što je sveprisutan, lako se podešava i koristi.

Da biste klonirali repozitorijum preko SSH-a, možeet da specificirate ssh:// URL ovako:

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

Ili možete da koristite kraću sintaksu koja podseća na scp za SSH protokol:

$ git clone user@server:project.git

Možete i da ne navedete korisnika, i Git će pretpostaviti da se radi o korisniku na koga ste trenutno ulogovani.

Prednosti

Mnoge su prednosti SSH-a. Za početak, SSH je lak za podešavanje — SSH demoni su banalni, mnogi mrežni administratori imaju iskustvo s njima, i mnoge distribucije operativnih sistema su podešene tako da imaju alate za rad sa njima. Zatim, pristup SSH-u je bezbedan — sav prenos podataka je enkriptovan i autentifikovan. Za kraj, kao i HTTP/S, SSH je efikasan, jer kompresuje podatke što je više moguće pre nego što započne prenos.

Mane

Negativna strana SSH-a je to što ne možete pružiti anonimni pristup repozitorijumu. Ljudi moraju da imaju pristup mašini da preko SSH-a da bi joj pristupili, čak i samo za čitanje, što ne čini SSH pogodnim za korišćenje u slučaju da se radi o projektu otvorenog koda. Ako ga koristite samo unutar korporativne mreže, SSH bi mogao da bude jedini protokol koji treba da koristite. Ako želite da dozvolite anonimni pristup za čitanje svojim projektima, ali istovremeno želite da koristite SSH, moraćete da podesite SSH za vas da gurate premene, ali i nešto drugo preko čega će ostali moći da pribavljaju podatke.

Git protokol

Sledeći je Git protokol. Ovo je posebni demon koji dolazi u paketu s Gitom; sluša na posvećenom portu (9418) koji nudi usluge slučne SSH protokolu, ali bez ikakve autentifikacije. Kako bi se repozitorijum servirao preko Git protokola, morate da kreirate datoteku git-daemon-export-ok — demon neće servirati repozitorijum ako taj fajl ne postoji — ali sem toga, nema nikakvih sigurosnih mera. Git repozitorijum je ili dostupan svima ili nije. Ovo znači da u opšem slučaju nije moguće guranje preko ovog protokola. Možete da omogućite pristup za pisanje; ali pošto nema autentifikacije, ako uključite ovo, svako na internetu ko nađe URL vašeg projekta će moći da gura svoje izmene na njega. Nema potrebe posebno naglašavati da je ovakva upotreba retkost.

Prednosti

Git protokol je često najbrži dostupni mrežni protokol za prenos podataka. Ako treba opslućiti veliki saobraćaj za javni projekat ili veoma veliki projekat koji ne zahteva autentifikaciju korisnika za čitanje, verovatno biste želeli da podesite Git demona koji će servirati vaš projekat. Koristi isti mehanizam za prenos podataka kao SSH protokol, ali bez dodatnih troškova za enkripcicju i autentifikaciju.

Mane

Mana Git protokola je nepostojanje autentifikacije. U opštem slučaju nije poželjno da Git protokol bude jedini način za pristup projektu. Obično ćete ga upariti sa SSH-om ili HTTP-om za nekoliko developera koji imaju pristup pisanju po njemu, a svi ostali mogu da koriste git:// za čitanje. Takođe je verovatno najkomplikovaniji protokol za podešavanje. Mora da se pokrene svojim demonom, koji zahteva konfiguraciju xinted ili neku konfiguracju slično njoj, što nije uvek baš toliko jednsotavno. Sem toga, zahteva da fajervol dopusti pristup portu 9418, što nije standardni port koji bi korporativni fajerfvolovi dopustili. Iza velikih korporativnih fajervolova, ovaj port je najčešće blokiran.