Git
Chapters ▾ 2nd Edition

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

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

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

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

Удаљени репозиторијум је у општем случају огољени репозиторијум — Гит репозиторијум који нема радни директоријум. Пошто се репозиторијум користи само као тачка за сарадњу, нема разлога да на диску има одјављен снимак; то су само подаци програма Гит. Најједноставније речено, огољени репозиторијум је садржај .git директоријума вашег пројекта и ништа друго.

Протоколи

Програм Гит може да користи четири главна протокола за пренос података: Локални, HTTP, Secure Shell (SSH) и Гит. Овде ћемо размотрити шта су они и у каквим околностима бисте желели (или не бисте желели) да их користите.

Локални протокол

Најосновнији је Локални протокол, код кога се удаљени репозиторијум налази у неком другом директоријуму на диску. Ово се често користи ако сви у тиму имају приступ дељеном фајл систему као што је NFS, или у мање вероватном случају ако се сви пријављују на исти рачунар. Други случај не би био идеалан, јер би се све инстанце кода из репозиторијума налазиле на истом рачунару, чиме би катастрофални губитак података био вероватнији.

Ако имате прикачен дељени фајл систем (shared mounted filesystem), онда можете да клонирате локални репозиторијум, да гурате на њега и да повлачите са њега. Да бисте клонирали овакав репозиторијум или га додали као удаљени неком постојећем пројекту, употребите путању до репозиторијума као URL. На пример, да бисте клонирали локални репозиторијум, извршите нешто овако:

$ git clone /opt/git/project.git

Можете да урадите и следеће:

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

Програм Гит ради мало другачије ако експлицитно наведете file:// на почетку УРЛ адресе. Ако наведете само путању, програм Гит покушава да користи чврсте линкове или да директно копира фајлове који су му потребни. Ако наведете file://, програм Гит покреће процес који обично користи за пренос података преко мреже, а који је у општем случају много мање ефикасна метода за пренос података. Главни разлог због кога бисте можда желели да наведете префикс file:// је уколико желите чисту копију репозиторијума са избаченим сувишним референцама или изостављеним објектима — рецимо после импорта са другог система за контролу верзије или нешто слично (погледајте Гит изнутра у вези послова око одржавања.) Овде ћемо користити нормалну путању јер је тако скоро увек брже.

Да бисте додали локални репозиторијум у постојећи Гит пројекат, можете да извршите нешто овако:

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

Онда можете да гурате и да повлачите са тог удаљеног репозиторијума преко новог имена удаљеног local_proj као да то радите преко мреже.

Предности

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

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

Мане

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

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

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

HTTP протоколи

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

Паметни HTTP

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

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

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

Приглуп HTTP

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

$ 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

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

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

У овом случају, користимо путању /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 је такође и мрежни протокол са аутентификацијом, а пошто је свеприсутан, у општем случају се лако подешава и користи.

Да бисте клонирали репозиторијум преко SSH, можете на следећи начин да наведете ssh:// URL:

$ git clone ssh://[корисник@]сервер/project.git

Или можете употребити краћу синтаксу која подсећа на scp за SSH протокол:

$ git clone [корисник@]сервер:project.git

У оба претходна случаја није обавезно да наведете корисника, програм Гит ће у том случају претпоставити да се ради о кориснику који је тренутно пријављен на систем.

Предности

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

Мане

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

Гит протокол

На реду је Гит протокол. Ово је посебни демон који долази уз програм Гит; он слуша на одређеном порту (9418) и нуди услуге сличне SSH протоколу, али без икакве аутентификације. Да би се репозиторијум сервирао преко Гит протокола, морате да креирате датотеку git-daemon-export-ok — демон неће сервирати репозиторијум ако тај фајл не постоји — али осим тога, нема никаквих сигурносних мера. Гит репозиторијум је или доступан свима или није уопште. Ово значи да у општем случају није могуће гурање преко овог протокола. Можете да омогућите приступ за писање; али пошто нема аутентификације, ако то укључите, свако на интернету ко нађе URL адресу вашег пројекта ће моћи да гура своје измене на њега. Нема потребе посебно наглашавати да је оваква употреба реткост.

Предности

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

Мане

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

scroll-to-top