Git
Chapters ▾ 2nd Edition

4.1 Git na strežniku - Protokoli

Na tej točki bi morali znati narediti večino dnevnih opravil, za katera boste uporabljali Git. Vendar pa morate za kakršno koli sodelovanje v Gitu imeti oddaljeni repozitorij Git. Čeprav lahko tehnično potisnete in povlečete spremembe iz posameznih repozitorijev, se to odsvetuje, ker lahko precej enostavno zamešate, na čem se dela, če niste pazljivi. Poleg tega želite, da lahko vaši sodelavci dostopajo do repozitorija, tudi če je vaš računalnik brez povezave — imeti bolj zanesljiv skupni repozitorij je pogostokrat uporabno. Zato je želena metoda za sodelovanje z nekom nastaviti vmesni repozitorij, do katerega imata oba dostop ter potiskate in vlečete iz njega.

Poganjanje strežnika Git je precej enostavno. Prvo izberete, katere protokole želite, da z njimi strežnik komunicira. Prvi razdelek tega poglavja bo pokril protokole, ki so na voljo, ter prednosti in slabosti vsakega. Naslednji razdelek bo razložil nekatere tipične nastavitve z uporabo teh protokolov in kako pripravite svoj strežnik, da dela z njimi. Nazadnje bomo šli skozi nekaj možnosti gostovanja, če nimate težav z gostovanjem svoje kode na strežniku nekoga drugega in ne želite prestati težav nastavitev in vzdrževanja svojega lastnega strežnika.

Če nimate nobenega interesa poganjati vašega lastnega strežnika, lahko preskočite na zadnji razdelek poglavja, da vidite nekaj možnosti nastavitev gostujočega računa in se nato premaknete na naslednje poglavje, kjer bomo govorili o različnih podrobnostih dela v porazdeljenem okolju upravljanja izvorne kode.

Oddaljeni repozitorij je v splošnem goli repozitorij — repozitorij Git, ki nima delovnega direktorija. Ker je repozitorij uporabljen samo kot točka sodelovanja, ni razloga imeti posnetka izvlečenega na disk; gre samo za podatke Git. Najenostavnejše rečeno, goli repozitorij je vsebina vašega projektnega direktorija .git in nič drugega.

Protokoli

Git lahko uporablja štiri glavne protokole za prenos podatkov: Local, HTTP, Secure Shell (SSH) in Git. Tu bomo govorili, kaj so in katere osnovne okoliščine bi želeli (ali ne želeli) imeti, da jih uporabljate.

Lokalni protokol

Najosnovnejši je lokalni protokol (angl. local), kjer je oddaljeni repozitorij v drugem direktoriju na disku na istem gostitelju. To se uporablja pogostokrat, če imajo vsi v vaši ekipi dostop do deljenega datotečnega sistema, kot je priklop (angl. mount) NFS, ali v manj verjetnem primeru, da se vsi prijavijo v isti računalnik. Zadnje ne bi bilo idealno, ker bi vse vaše instance repozitorija kode domovale na istem računalniku, kar naredi katastrofične izgube bolj verjetne.

Če imate deljeni priklopljeni datotečni sistem, potem lahko klonirate, potiskate in vlečete iz lokalnega datotečno osnovanega repozitorija. Da tako klonirate repozitorij ali ga dodate kot oddaljenega k obstoječemu projektu, uporabite pot do repozitorija kot URL. Na primer, da klonirate lokalni repozitorij, lahko poženete nekaj takega:

$ git clone /srv/git/project.git

Ali pa lahko naredite to:

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

Git operira malenkost drugače, če izrecno določite file:// na začetku URL-ja. Če določite samo pot, Git poskuša uporabiti trde povezave ali pa neposredno kopira datoteke, ki jih potrebuje. Če določite file://, Git požene proces, ki ga običajno uporablja za prenos datotek podatkov preko omrežja, kar je v splošnem veliko manj učinkovita metoda. Glavni razlog za določanje predpone file:// je, da želite čisto kopijo repozitorija z izpuščenimi neznanimi referencami ali objekti — v splošnem po uvozu iz drugega sistema nadzora različic ali česa podobnega (glejte poglavje Notranjost Gita za opravila vzdrževanja). Tu bomo uporabili običajno pot, saj je to skoraj vedno hitrejše.

Da dodate lokalni repozitorij obstoječemu projektu Git, lahko poženete nekaj takega:

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

Nato lahko potiskate ali vlečete iz te daljave preko vaše nove daljave imenovane local_proj, kot bi to naredili preko omrežja.

Prednosti

Prednosti datotečno osnovanih repozitorijev so, da so enostavni in da uporabljajo obstoječe pravice datotek in dostopa omrežja. Če že imate deljeni datotečni sistem, do katerega ima dostop celotna ekipa, je nastavitev repozitorija zelo enostavna. Prilepite golo kopijo repozitorija nekam, kjer ima vsakdo deljeni dostop in nastavite pravice pisanja/branja, kakor bi to naredili za katerikoli drugi deljeni direktorij. S tem namenom bomo v razdelku Pridobitev Gita na strežniku govorili, kako izvoziti golo kopijo repozitorija.

To je tudi dobra možnost za hitro prijetje dela iz delovnega repozitorija nekoga drugega. Če vi in vaš sodelavec delata na istem projektu in od vas želi, da nekaj pogledate, je pogon ukaza, kot je git pull /home/john/project, pogostokrat enostavnejši kot potiskanje na oddaljeni strežnik in da nato prenesete od tam.

Slabosti

Slabosti te metode so, da je deljeni dostop v splošnem težje nastaviti in doseči iz več lokacij kot pa osnovni dostop omrežja. Če želite potisniti iz svojega prenosnika, ko ste doma, morate priklopiti oddaljeni disk, kar je lahko težko in počasno v primerjavi z dostopom na osnovi omrežja.

Pomembno je omeniti, da to ni nujno najhitrejša možnost, če uporabljate neke vrste deljeni priklop. Lokalni repozitorij je hiter samo, če imate hiter dostop do podatkov. Repozitorij na NFS je pogostokrat počasnejši kot repozitorij preko SSH na istem strežniku, kar omogoča Gitu, da poganja lokalne diske na vsakem sistemu.

In nazadnje, ta protokol ne ščiti repozitorija pred škodo po nesreči. Vsak uporabnik ima polni lupinski dostop do »oddaljenega« direktorija in nič jim ne preprečuje spremeniti ali odstraniti notranjih datotek Git ter poškodovati repozitorija.

Protokoli HTTP

Git lahko komunicira preko HTTP v dveh različnih načinih. Pred različico Git 1.6.6 je bil samo en način, da to lahko naredi, kar je bilo zelo enostavno in v splošnem samo za branje. V različici 1.6.6 je bil predstavljen nov pametni protokol, ki je vključeval, da je bil Git sposoben se pametno pogajati pri prenosu podatkov na podoben način, kakor to dela preko SSH. V zadnjih nekaj letih je ta novi protokol HTTP postal zelo popularen, saj je enostavnejši za uporabnika in pametnejši, kako komunicira. Novejša različica je pogostokrat omenjena kot protokol Smart HTTP in starejši način kot Dumb HTTP. Najprej bomo pokrili novejši protokol Smart HTTP.

Pametni HTTP

Pametni oz. t. i. Smart protokol HTTP operira zelo podobno kot protokola SSH ali Git, vendar se poganja preko standardnih vrat HTTPS in lahko uporablja različne mehanizme overjanja HTTP, kar pomeni, da je enostavnejši na uporabniški strani kot SSH, saj lahko uporabite stvari, kot je osnovno overjanje z uporabniškim imenom in geslom namesto nastavljanja ključev SSH.

Verjetno je sedaj postal najpopularnejši način za uporabo Gita, saj je lahko nastavljen tako, da streže tako anonimno, kot je protokol git://, kot je tudi lahko potisnjen preko z overjanjem in šifriranjem, kakršen je protokol SSH. Namesto da morate za te stvari nastavljati različne URL-je, lahko sedaj uporabite en URL za oba. Če poskusite potisniti in repozitorij zahteva overjanje (kar bi običajno moral), strežnik lahko vpraša za uporabniško ime in geslo. Enako velja za bralni dostop.

V bistvu za storitve, kot je GitHub, je URL, ki ga uporabljate za ogled repozitorija na spletu (na primer https://github.com/schacon/simplegit), enak URL-ju, ki ga lahko uporabite za kloniranje in potiskanje, če imate dostop.

Neumni HTTP

Če se strežnik ne odzove s pametno storitvijo Git HTTP, se bo odjemalec Git poskušal vrniti k enostavnejšemu neumnemu (angl. dumb) protokolu HTTP. Neumni protokol pričakuje, da je goli repozitorij Git ponujen kot običajne datoteke s spletnega strežnika. Lepota neumnega protokola HTTP je enostavnost nastavitve. V osnovi je vse, kar morate narediti, dati goli repozitorij Git pod vaš vrhnji dokumentni direktorij HTTP in nastaviti določeno kljuko post-update ter ste zaključili (glejte razdelek Kljuke Git). Na tej točki kdorkoli, ki lahko dostopa do spletnega strežnika, pod katerim ste dali repozitorij, lahko tudi klonira vaš repozitorij. Da omogočite bralni dostop do svojega repozitorija preko HTTP, naredite nekaj takega:

$ 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 vse. Kljuka post-update, ki prihaja privzeto z Gitom, požene ustrezni ukaz (git update-server-info), da naredi prenašanje in kloniranje HTTP ustrezno delujoče. Ta ukaz se izvede, ko potisnete v ta repozitorij (morda preko SSH); nato lahko ostali ljudje klonirajo preko tega nekako takole:

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

V tem določenem primeru uporabljamo pot /var/www/htdocs, ki je pogosta za nastavitve Apache, vendar lahko uporabite katerikoli statični spletni strežnik — v njegovo pot samo podajte goli repozitorij. Podatki Git so ponujeni kot osnovne statične datoteke (za podrobnosti, kako točno je strežen, glejte poglavje Notranjost Gita).

V splošnem bi izbrali, da se poganja bralno/pisalni strežnik s pametnim HTTP, ali pa imate datoteke enostavno dostopne samo za branje v neumnem načinu. Redko se poganja mešanica obeh storitev.

Prednosti

Osredotočili se bomo na prednosti pametne verzije protokola HTTP.

Enostavnost enega URL-ja za vse tipe dostopov in da strežnik poziva samo, ko je potrebno overjanje, naredi stvari zelo enostavne za končnega uporabnika. Možnost overjanja z uporabniškim imenom in geslom je tudi velika prednost pred SSH, saj uporabnikom ni treba lokalno generirati ključev SSH in naložiti njihovih javnih ključev na strežnik, preden imajo lahko interakcijo z njim. Za manj zahtevne uporabnike ali uporabnike na sistemih, kjer je SSH manj pogost, je to glavna prednost uporabnosti. Protokol je tudi zelo hiter in učinkovit, podobno, kot je SSH.

Svoje repozitorije lahko ponudite preko HTTPS tudi samo za branje, kar pomeni, da lahko šifrirate vsebino prenosa; ali pa greste dalje in naredite, da odjemalci uporabljajo določene podpisane certifikate SSL.

Druga dobra stvar je, da sta HTTP in HTTPS tako pogosto uporabljena protokola, da so požarni zidovi podjetij pogostokrat nastavljeni, da omogočajo promet preko njunih vrat.

Slabosti

Git je lahko na nekaterih strežnikih bolj zahtevno nastaviti preko HTTPS v primerjavi s SSH. Razen tega je zelo malo prednosti, ki jih imajo ostali protokoli pred pametnim protokolom HTTP za strežbo Gita.

Če uporabljate HTTP za overjeno potiskanje, je zagotavljanje vaših poverilnic včasih bolj komplicirano kot uporaba ključev preko SSH. Vendar na voljo je kar nekaj orodij predpomnjenja poverilnic, ki jih lahko uporabite, vključno s Keychain na sistemu macOS in Credential Manager na sistemu Windows, kar naredi to precej neboleče. Preberite razdelek Shramba poverilnic, da si pogledate, kako nastaviti varno predpomnjenje gesel HTTP na vašem sistemu.

Protokol SSH

Pogosti protokol prenosa, ko Git gostujete sami, je preko SSH. To je zato, ker je dostop SSH na strežnikih večinoma že nastavljen — in če ni, je to enostavno narediti. SSH je tudi overitveni omrežni protokol in, ker je vseprisoten, ga je v splošnem enostavno nastaviti in uporabljati.

Da klonirate repozitorij Git preko SSH, lahko določite ssh:// URL takole:

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

Lahko pa uporabite kratko scp-podobno sintakso za protokol SSH:

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

V obeh primerih zgoraj, če ne določite neobveznega uporabnika, Git predpostavlja, da gre za uporabnika, ki je trenutno prijavljen.

Prednosti

Prednosti za uporabo SSH je mnogo. Najprej, SSH je relativno enostavno nastaviti — prikriti procesi SSH so pogosti, mnogi administratorji omrežij imajo z njimi izkušnje in mnoge distribucije OS so z njimi nastavljene ali pa imajo orodja za njihovo upravljanje. Naslednje, dostop preko SSH je varen — vsi poslani podatki so šifrirani in overjeni. Nazadnje, tako kot protokoli HTTPS, Git in lokalni protokol, je tudi SSH učinkovit, saj so podatki pred prenašanjem čim bolj kompaktni.

Slabosti

Negativni pogled SSH-ja je, da ne podpira anonimnega dostopa do vašega repozitorija. Če uporabljate SSH, morajo imeti ljudje dostop do vaše naprave preko SSH, tudi samo v načinu za branje, kar SSH ne naredi ugodnega za odprtokodne projekte, kjer uporabniki želijo samo enostavno klonirati vaš repozitorij, da ga preučijo. Če ga uporabljate samo znotraj svojega omrežja podjetja, je SSH lahko edini protokol, s katerim se boste morali ukvarjati. Če želite dovoliti anonimen dostop samo za branje do svojih projektov in želite uporabljati tudi SSH, boste morali nastaviti SSH, da lahko potiskate preko njega, vendar nekaj drugega za druge, da lahko prenašajo.

Protokol Git

Nazadnje je na voljo protokol Git. To je posebni prikriti proces, ki prihaja v paketu Git; posluša na namenskih vratih (9418), kar ponuja storitev podobno kot protokol SSH, vendar absolutno brez vsakršnega overjanja ali šifriranja. Da je lahko repozitorij postrežen preko protokola Git, morate ustvariti datoteko git-daemon-export-ok — prikriti proces ne bo stregel repozitorija brez te datoteke v njem — vendar razen tega ni nikakršne varnosti. Bodisi je repozitorij Git na voljo za vsakogar za kloniranje, ali pa sploh ni. To pomeni, da v splošnem ni nobenega potiskanja preko tega protokola. Lahko omogočite dostop potiskanja; vendar bo manjkalo overjanje, kar pomeni, da kdorkoli na internetu, ki najde URL vašega projekta, lahko potisne v ta projekt. Dovolj je reči, da je to redko.

Prednosti

Protokol Git je pogostokrat najhitrejši omrežni protokol, ki je na voljo. Če ponujate veliko prometa za javni projekt ali strežete zelo velik projekt, ki ne zahteva uporabniškega overjanja za dostop branja, je verjetno, da boste želeli nastaviti prikriti proces Git, da streže vaš projekt. Uporablja enak mehanizem prenosa podatkov kot protokol SSH, vendar brez režijskih stroškov šifriranja in overjanja.

Slabosti

Zaradi pomanjkanja TLS ali druge kriptografije lahko kloniranje prek git:// privede do ranljivosti za izvajanje poljubne kode, zato se mu izogibajte, razen če veste, kaj počnete.

  • Če zaženete git clone git://example.com/project.git, lahko napadalec, ki nadzoruje vaš usmerjevalnik, spremeni pred kratkim kloniran repozitorij in vanj vstavi zlonamerno kodo. Če nato prevedete/zaženete kodo, ki ste jo pravkar klonirali, bo izvedena tudi zlonamerna koda. Zaradi istega razloga se je treba izogibati tudi zagonu git clone http://example.com/project.git.

  • Zagon git clone https://example.com/project.git nima take težave (razen če napadalec lahko poda certifikat TLS za example.com). Zagon git clone git@example.com:project.git ima težavo samo, če sprejmete napačni prstni odtis SSH.

Protokol Git tudi nima overjanja, torej lahko repozitorij klonira kdorkoli (čeprav je to pogosto prav tisto, kar želite). Poleg tega je najverjetneje najtežji protokol za nastavitev. Zahteva svoj prikriti proces, kar zahteva konfiguracijo xinetd, systemd, ali kaj podobnega, kar ni vedno preprosto. Prav tako zahteva dostop do požarnega zidu na vratih 9418, ki niso standardna vrata, ki jih požarni zidovi podjetij vedno dovoljujejo. Za velikimi požarnimi zidovi podjetij so ta neznana vrata pogosto blokirana.

scroll-to-top