Git
Chapters ▾ 2nd Edition

4.1 Git na strežniku - Protokoli

Na tej točki, bi morali biti sposobni narediti večino dnevnih opravil zaradi katerih boste uporabljali Git. Vendar, da naredite kakršno koli sodelovanje v Git-u, boste potrebovali imeti oddaljeni Git repozitiorij. Čeprav lahko tehnično porinete spremembe v in potegnete spremembe iz posameznih repozitorijev, se to ne svetuje, ker lahko precej enostavno zamešate, na čemer se dela, če niste pazljivi. Poleg tega želite, da vaši sodelavci lahko dostopajo do repozitorija tudi če je vaš računalnik offline - imeti bolj zanesljiv skupni repozitorij je pogostokrat uporabno. Zato je željena metoda za sodelovanje z nekom nastaviti vmesni repozitorij, do katerega imata oba dostop ter porinete in potegnete iz njega.

Poganjanje Git strežnika je precej enostavno. Prvo izberete, katere protokole želite, da z njimi strežnik komunicira. Prva sekcija tega poglavja bo pokrila protokole, ki so na voljo ter prednosti in slabosti vsakega. Naslednja sekcija bo razložila nekatere tipične nastavitve z uporabo teh protokolov in kako pripravite vaš strežnik, da dela z njimi. Zadnje bomo šli skozi nekaj opcij gostovanja, če nimate težav z gostovanjem vaše kode na strežniku nekoga drugega in ne želite iti skozi težave nastavitev in vzdrževanja vašega lastnega strežnika.

Če nimate nobenega interesa poganjati vaš lastni strežnik, lahko zadnjo sekcijo poglavja preskočite, da vidite nekaj opcij nastavitev gostujočega računa in se nato premaknete na naslednje poglavje, kjer bomo govorili o različnih vhodih in izhodih dela v distribuiranem okolju upravljanje izvorne kode.

Oddaljeni repozitorij je v splošnem goli repozitorij - Git repozitorij, ki nima delujočega direktorija. Ker je repozitorij uporabljen samo kot točka sodelovanja, ni razloga imati posnetek izpisan na disk; gre samo za podatke Git. V najenostavnejših terminih, 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 imeti (ali ne želeli), da jih uporabljate.

Lokalni protokoli

Najbolj osnovni je lokalni protokol v katerem je oddaljeni repozitorij v drugem direktoriju na disku. To je pogostokrat uporabljeno, če vsi v vaši ekipi imajo dostop do deljenega datotečnega sistema, kot je NFS mount ali v manj verjetnem primeru se vsi prijavijo v isti računalnik. Zadnje ne bi bilo idealno, ker vsa vaša instanca repozitorija kode bi domovala na istem računalniku, kar naredi katastrofične izgube bolj verjetne.

Če imate priklopljen deljeni datotečni sistem, potem lahko klonirate, porivate in potegnite iz lokalnega datotečno osnovanega repozitorija. Da tako klonirate repozitorij ali enega dodate kot oddaljenega k obstoječemu projektu, uporabite pot do repozitorija kot URL. Na primer, da klonirate lokalni repozitorij, lahko poeženete nekaj takega:

$ git clone /opt/git/project.git

Or you can do this:

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

Git operira malenkost drugače, če eksplicitno določite file:// na začetku URL-ja. Če samo določite pot, Git poskuša uporabiti trde povezave ali direktno kopiranje datotek, ki jih potrebuje. Če določite file://, Git požene proces, ki ga običajno uporablja za prenos datotek podatkov preko omrežja, ki je v splošnem veliko manj efektivna metoda prenosa podatkov. Glavni razlog za določanje predpone file:// je, če želite čisto kopijo repozitorija z izpuščenimi tujimi referencami ali objekti - v splošnem po importiranju iz drugega sistema kontrole verzij ali nečesa podobnega (glejte Notranjost Git-a za opravila vzdrževanja). Tu bomo uporabili običajno pot, ker je to skoraj vedno hitrejše.

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

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

Nato lahko porinete ali potegnete iz tega oddaljenega, 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. Lahko se držite gole kopije repozitorija nekje, kjer ima vsakdo deljeni dostop in nastavite pravice pisanja/branja, kakor bi to naredili za katerikoli drugi deljeni direktorij. Govorili bomo, kako izvoziti golo kopijo repozitorija za ta razlog v Pridobiti Git na strežnik.

To je tudi lepa opcija za hitro prijetje dela iz delovnega repozitorija nekoga drugega. Če vi in vaš sodelavec delate na istem projektu in želijo nekaj izpisati, je pogon ukaza, kot je git pull /home/john/project, pogostokrat enostavnejši kot porivanje v oddaljeni strežnik in da nato potegnete.

Slabosti

Slabosti te metode so, da je deljeni dostop v splošnem težji za nastaviti in doseči iz večih lokacij kot osnovni dostop omrežja. Če želite poriniti iz vašega 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 opcija, če uporabljate deljeni priklop neke vrste. 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 Git-u, da poganja lokalne diske na vsakem sistemu.

In nazadnje, ta protokol ne ščiti repozitorijev proti škodi po nesreči. Vsak uporabnik ima polni lupinski dostop do odaljenega direktorija in nič mu ne preprečuje spremeniti ali odstraniti notranje Git datoteke in poškodovati repozitorij.

HTTP protokoli

Git lahko komunicira preko HTTP v dveh različnih načinih. Pred 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 verziji 1.6.6 je bil predstavljen nov pametni protokol, ki je vključeval Git, da je bil sposoben inteligentno pogajati prenos podatkov na način podoben, kakor to dela preko SSH. V zadnjih nekaj letih, je ta novi HTTP protokol postal zelo popularen, saj je enostavnejši za uporabnika in pametnejši kako komunicira. Novejša verzija je pogostokrat sklicana kot “Smart” HTTP protokol in starejši način kot “Dump” HTTP. Najprej bomo pokrili novejši “smart” HTTP protokol.

Pametni HTTP

Pametni oz t.i. “smart” HTTP protokol operira zelo podobno kot SSH ali Git protokola vendar teče preko standardnih HTTP/S portov in lahko uporablja različne HTTP mehanizne avtentikacije, kar pomeni, da je enostavnejši na uporabniški strani kot SSH, odkar lahko uporabite stvari kot je osnovna avtentikacija z uporabniško imenom in geslom namesto, da morate nastaviti ključe SSH.

Verjetno je sedaj postal najpopularnejši način za uporabo Git-a, saj je lahko nastavljen, da ponuja tako anonimne, kot je protokol git://, in lahko je poslan tudi preko z overitvijo in ekripcijo kot je protokol SSH. Namesto, da morate nastavljati različne URL-je za te stvari, lahko sedaj uporabite en URL za oba. Če poskusite potisniti in repozitorij zahteva overitev (kar bi običajno moral), strežnika lahko vpraša za uporabniško ime in geslo. Isto gre 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, ki ga lahko uproabite za kloniranje in, če imate dostop potiskanje.

Neumni HTTP

Če se strežnik ne odzove s pametno Git HTTP storitvijo, se bo Git klient poskušal vrniti k enostavnejšemu “dump” protokolu HTTP. Neummni protokol pričakuje, da je goli repozitorij Git ponujen kot običajne datoteke s spletnega strežnika. Lepota neumnega HTTP protokola je enostavnost nastavitve. V osnovi je vse kar morte narediti, dati goli repozitorij Git pod vaš vrhnji HTTP dokumenti direktorij in nastaviti določeno kjuko post-update in ste končali (Glejte Git kljuke). Na tej točki kdorkoli lahko dostopa do spletnega strežnika pod katerim ste dali repozitorij in lahko tudi klonira vaš repozitorij. Da omogočite bralni dostop do vašega 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 z Git-om privzeto poganja ustrezni ukaz (git update-server-info), da naredite HTTP ujetje in kloniranje ustrezno delujoče. Ta ukaz se izvede, ko potisnete v ta repozitorij (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 - samo dajte goli repozitorij v njegovo pot. Podatki Git so ponujeni kot osnovne statične datoteke (glejte Notranjost Git-a za podrobnosti o tem, kako točno je ponujen).

V splošnem bi ali izbrali, da se poganja bralno/pisalni pametni HTTP strežnik ali enostavno imate datoteke dostopne kot samo bralno v neumnem načinu. Redko je poganjati mešanico obeh storitev.

Prednosti

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

Enostavnost imetja enega URL-ja za vse tipe dostopov in imeti strežniški poziv samo ko je potrebna overitev, naredi stvari zelo enostavne za končnega uporabnika. Da ste zmožni overiti z uporabniškim imenom in geslom je tudi velika prednost preko SSH, saj uporabnikom ni treba generirati SSH ključev lokalno in naložiti njihovih javnih ključev strežniku preden so zmožni imeti interakcijo z njim. Za manj sofisticirane uporabnike ali uporabnike na sistemih, kjer je SSH manj pogost, je to glavna prednost v uporabnosti. Je tudi zelo hiter in učinkovit protokol, podobno kot je SSH.

Lahko tudi ponudite vaše repozitorije kot samo bralne preko HTTPS, kar pomeni, da lahko šifrirate vsebino prenosa; ali lahko greste dalje in naredite, da klienti uporabljajo določene podpisane SSL certifikate.

Druga lepa stvar je, da so HTTP/S tako pogosto uporabljeni protokoli, da so korporacijski požarni zidovi pogostokrat nastavljeni, da omogočajo promet preko teh portov.

Slabosti

Git je lahko preko HTTP/S bolj zahtevek za nastaviti v primerjavi s SSH na nekaterih strežnikih. Razen tega je zelo malo prednosti, ki jih imajo ostali protokoli preko “pametnega” HTTP protokola za ponujanje Git-a.

Če uporabljate HTTP za overitveno porivanje, je ponujanje vaših poverilnic včasih bolj komplicirano kot uporaba ključev preko SSH. Vendar so nekatera orodja predpomnjenja poverilnic, ki jih lahko uporabite, vključno s Keychain dostopom na OSX in Credential Manager-jem na Windows, da naredi to precej neboleče. Preberite Credential Storage, da vidite kako nastaviti varno predpomnenje HTTP gesel na vašem sistemu.

Protokol SSH

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

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

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

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

$ git clone user@server:project.git

Lahko tudi ne določite uporabnika in Git predpostavlja, da je uporabnik trenutno prijavljen kot je.

Prednosti

Prednosti za uporabo SSH je mnogo. Najprej, SSH je relativno nastaviti - SSH prikriti procesi so pogosti, mnogi administratorji omrežij imajo izkušnje z njimi in mnoge OS distribucije so nastavljene z njimi ali imajo orodja za njihovo upravljanje. Naslednje, dostop preko SSH je varen - vsi poslani podatki so šifrirani in overjeni. Zadnje, kot HTTP/S, Git in lokalni protokoli je SSH učinkovit, kar naredi podatke kompaktne kolikor je možno pri prenašanju.

Slabosti

Negativni pogled SSH-ja je, da ne morete ponujati anonimnega dostopa vašega repozitorija preko tega. Ljudje morajo imeti dostop do vaše napravve preko SSH, tudi v zmožnosti samo branja, kar ne naredi SSH dostopa prevodnega za odprtokodne projekte. Če ga uporabljate samo znotraj vašega organizacijskega omrežja, je SSH lahko edini protokol s katerim se boste morali ukvarjati. Če želite dovoliti anonimen samo bralni dostop do vaših projektov in tudi želite uporabljati SSH, boste morali nastaviti SSH, da lahko potiskate preko njega, vendar nekaj drugega za ostale, da lahko ujemajo.

Protokol Git

Naslednji je protokol Git. To je posebni prikriti proces, ki prihaja v paketu z Git-om; posluča na namenskem portu (9418), ki ponuja storitev podobno protokolu SSH, vendar z absolutno brez overjanja. Da je lahko repozitorij ponujen preko protokola Git, morate ustvariti datoteko git-daemon-export-ok - prikriti proces ne bo ponujal repozitorija brez te datoteke v njem - vendar razen tega ni nobene varnosti. Bodisi je repozitorij Git na voljo za vsakogar, da klonira ali pa ni. To pomeni, da v splošnem ni nobenega potiskanja preko tega protokola. Lahko omogočite dostop porivanja; vendar z danim manjkanjem overjanja, če vključite dostop potiskanja, kdorkoli na internetu, ki najde URL vašega projekta, lahko potisne v vaš projekt. Dovolj je reči, da je to redko.

Prednosti

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

Slabosti

Slabost protokola Git je pomanjkanje overjanja. V splošnem ni zaželjeno za protokol Git, da je edini dostop do vašega projekta. V splošnem ga boste združili z dostopom SSH ali HTTPS za nekaj razvijalcev, ki imajo dostop potiskanja (branje) in za vse ostale uporabili git:// za dostop samo branja. Je verjetno tudi najbolj težek protokol za nastaviti. Poganjati mora svoj lastni prikriti proces, ki zahteva xinetd nastavitve ali podobno, kar večinoma ni ravno sprehod po parku. Tudi zahteva dostop požarnega zidu za port 9418, kar ni standardni port, ki ga organizacijski požarni zidovi vedno dovoljujejo. Za velikimi organizacijskimi požarnimi zidovi je ta nejasen port pogostokrat blokiran.