4.1 Гит на серверу - Протоколи

Предности репозиторијума заснованих на фајловима су чињеница да су једноставни и да користе постојеће дозволе над фајловима и приступ мрежи. Ако већ имате дељени фајл систем коме цео тим приступа, подешавање оваквог репозиторијума је веома лако. Сместите огољену копију репозиторијума негде где сви имају дељени приступ и подесите дозволе за читање и упис као што бисте урадили и код било ког другог дељеног директоријума. У Постављање програма Гит на сервер ћемо дискутовати о томе како да извезете огољену копију репозиторијума за ову намену.

Ово је такође добра опција да брзо зграбите рад са туђег радног репозиторијума. Ако ви и сарадник радите на истом пројекту тај сарадник жели да нешто одјавите, извршавањем команде као што је git pull /home/john/project, често је то лакше него да сарадник гура податке на удаљени сервер, а да их ви након тога повучете.

Мане ове методе су то што је код дељеног приступа подешавање и приступање серверу са различитих локација у општем случају теже него код основног приступа мрежи. Ако желите да гурнете са лаптопа када сте кући, морате да монтирате удаљени диск, што може да буде тешко и споро у поређењу са приступом преко мреже.

Важно је поменути да ово није увек и најбржа опција ако користите неку врсту дељеног монтираног. Локални репозиторијум је брз само ако имате брз приступ подацима. Репозиторијум на NFS систему је често спорији него репозиторијум преко SSH на истом серверу, јер допушта програму Гит да се на сваком систему извршава са локалних дискова.

Коначно, овај протокол не штити репозиторијум од случајног оштећења. Сваки корисник има потпуни приступ „удаљеном” директоријуму преко командног окружења и ништа га не спречава да промени или уклони интерне фајлове програма Гит, па на тај начин поквари репозиторијум.

Паметни HTTP протокол ради слично као SSH или Гит протоколи, с тим што се обавља преко стандардних HTTPS портова и може да користи разне HTTP механизме за аутентификацију, што значи да је из перспективе корисника једноставнији за употребу него нешто као што је SSH, пошто омогућава употребу на пример, основне аутентификације корисничким именом и шифром, уместо SSH кључевима.

Ово је сада вероватно постао најпопуларнији начин за коришћење програм Гит, пошто се може подесити тако да пружа услуге и анонимно као протокол git://, али и помоћу аутентификације и шифровања као SSH протокол. Уместо да подешавате различите URL адресе за ове ствари, сада можете да користите само један URL за оба. Ако пробате да гурнете на репозиторијум који захтева аутентификацију (што би и требало да буде случај), сервер може да вам затражи корисничко име и лозинку. Исто важи и за приступ читањем.

Заправо, за сервисе као што је GitHub, URL адреса коју користите да на мрежи погледате репозиторијум (на пример, https://github.com/schacon/simplegit) је иста URL адреса коју можете користити за клонирање, а ако имате приступ, и за гурање.

Ако сервер не одговара паметним HTTP сервисом програма Гит, Гит клијент ће покушати да се повеже користећи једноставнији Приглуп HTTP протокол. Приглуп протокол очекује да се огољени Гит репозиторијум сервира као обични фајлови са веб сервера. Лепота Приглупог HTTP протокола је једноставност његовог подешавања. У основи, све што треба да урадите јесте да објавите огољени Гит репозиторијум под кореном HTTP докумената и да подесите специфичну post-update куку и то је то (погледајте Гит куке). Сада свако ко може да приступи веб серверу на који сте поставили репозиторијум може и да клонира ваш репозиторијум. Да бисте дозволили читање репозиторијума преко HTTP протокола, урадите нешто слично следећем:

И то је све. post-update кука која подразумевано долази уз програм Гит покреће одговарајућу команду (git update-sever-info) која омогућава да HTTP преузимање и клонирање ради како треба. Ова команда се покреће када гурате на овај репозиторијум (на пример преко SSH); затим други људи онда могу да клонирају користећи команду налик следећој:

У овом случају, користимо путању /var/www/htdocs која је честа код Apache сервера, али можете да користите и било који статички веб сервер — само поставите огољени репозиторијум у његову путању. Гит подаци се сервирају као обични статички фајлови (погледајте Гит изнутра за детаље о томе како се тачно обавља сервирање).

У општем случају треба да направите избор између Паметног HTTP сервера који нуди читање и упис, или да омогућите једноставан приступ само за читање користећи Приглуп приступ. Ова два сервиса се ретко мешају.

Концентрисаћемо се на предности Паметне верзије HTTP протокола.

Једноставност чињенице да постоји јединствена URL адреса за све врсте приступа, као и то што сервер од корисника захтева аутентификацију само онда када је она неопходна чини ствари много једноставнијим за крајњег корисника. То што је могућа аутентификација помоћу корисничког имена и шифре је такође велика предност над SSH протоколом, јер корисници не морају локално да генеришу SSH кључеве, па да јавни кључ постављају на сервер пре него што могу да успоставе комуникацију са њим. За мање софистициране кориснике, или за кориснике на системима где SSH није тако чест избор комуникације, ово је велика предност код употребљивости. Ово је такође веома брз и ефикасан протокол, сличан SSH протоколу.

Сем тога, преко HTTPS протокола своје репозиторијуме можете сервирати и само за читање, што значи да пренос садржаја можете да шифрујете; или можете да идете до те мере да натерате клијенте да користе посебне потписане SSL сертификате.

Још једна лепа ствар је то што су HTTP и HTTPS толико често коришћени протоколи да су корпоративни фајерволови често подешени тако да дозвољавају пренос таквог саобраћаја кроз своје портове.

Гит преко HTTPS протокола уме да буде мало незгоднији за подешавање у поређењу са подешавањем SSH на неким серверима. Сем тога, када је у питању пренос Гит садржаја, постоји врло мало предности које други протоколи нуде у односу на Паметни HTTP.

Ако користите HTTP за аутентификовано гурање, достављање акредитива је понекад компликованије него коришћење кључева преко SSH. Ипак, постоји неколико алата за кеширање акредитива које можете користити, укључујући Keychain приступ на мекОС и Credential Manager за Виндоуз, што ће учинити овај поступак прилично безболним. Прочитајте Складиште акредитива да бисте видели како да на свом систему подесите сигурни HTTP систем за кеширање лозинки.

Постоји много предности SSH протокола. За почетак, SSH је једноставан за подешавање — SSH демони су опште присутни, многи мрежни администратори имају искуство с њима и многе дистрибуције оперативних система су подешене тако да имају алате за рад са њима. Затим, приступ преко SSH је безбедан — сав пренос података се шифрује и аутентификује. За крај, као и HTTPS, Гит и Локални протокол, SSH је ефикасан, јер компресује податке што је више могуће пре него што започне пренос.

Лоша страна SSH протокола је то што не можете пружити анонимни приступ репозиторијуму. Ако користите SSH, људи морају да имају SSH приступ машини, чак и само за читање, што SSH не чини погодним за пројекте отвореног кода, где људи понекад само желе да клонирају ваш репозиторијум како би истражили кôд. Ако га користите само унутар корпоративне мреже, SSH би могао да буде једини протокол који треба да користите. Ако својим пројектима желите да дозволите анонимни приступ само за читање, али истовремено желите да користите SSH, за вас ћете морати да подесите SSH за гурање промена, али и нешто друго преко чега ће остали моћи да преузимају податке.

Гит протокол је често најбржи доступни мрежни протокол за пренос података. Ако треба опслужити велики саобраћај за јавни пројекат или веома велики пројекат који не захтева аутентификацију корисника за читање, вероватно ћете пожелели да подесите Гит демона који ће сервирати ваш пројекат. Користи исти механизам за пренос података као SSH протокол, али без додатних трошкова за шифровање и аутентификацију.

Мана Гит протокола је непостојање аутентификације. У општем случају није пожељно да Гит протокол буде једини начин за приступ пројекту. Обично ћете га упарити са SSH или HTTPS приступом за неколико програмера који имају дозволу за гурање (упис), а сви остали могу да користе git:// само за читање. Такође је вероватно најкомпликованији протокол за подешавање. Мора да покреће сопствени демон, који захтева xinted,systemd или неку сличну конфигурацију, што није увек баш толико једноставно. Сем тога, захтева да фајервол допусти приступ порту 9418, што није стандардни порт који би корпоративни фајерфволови допустили. Иза великих корпоративних фајерволова, овај неуобичајени порт је најчешће блокиран.