4.1 Git sa Server - Ang Mga Protokol

Ang mga kalamangan ng isang repositoryo na nakabatay sa file ay ang mga ito ay simple at ginagamit ang mga umiiral na mga pahintulot ng file at access sa network. Kapag ibinahagi mo na ang isang filesystem na kung saan may-access ang lahat ng iyong team, ang pag-set up ng isang repositoryo ay napakadali. Ilalagay mo ang kopya ng hubad na repositoryo sa kung saan may access ang lahat at i-set ang pagbasa/pagsulat na mga pahintulot katulad ng kahit anong ibinahagi na direktoryo. Tatalakayin natin kung papaano mag-export ng isang kopya ng hubad na repositoryo para sa itong layunin sa Pagkuha ng Git sa isang Server.

Ito rin ay isang magandang opsyon para sa mabilis na pagkuha ng trabaho mula sa gumagana na repositoryo ng iba. Kapag ikaw at ang isang katrabaho ay nagtatrabaho sa isang proyekto at gusto nila na may kunin ka, ang pagpapagana ng isang utos tulad ng git pull /home/john/project ay kadalasan mas madali kaysa mag-push sila sa isang remote na server at pagkatapos ay kukunin mo.

Ang mga kahinaan ng paraan na ito ay ang mga ibinahagi na access ay sa pangkalahatan mas mahirap i-set up at maabot mula sa maramihang mga lokasyon kaysa sa pangunahing network access. Kapag gusto mong mag-push mula sa iyong laptop kapag ikaw ay nasa bahay, kailangan mong i-mount ang remote dist, na maaaring maging mahirap at mahina kumpara sa batay sa network na access.

Mahalagang banggitin na hindi ito ang pinakamabilis na opsyon kung ikaw ay gumagamit ng isang uri ng ibinahagi na mount. Ang isang lokal na repositoryo ay mabilis lamang kapag ikaw ay may mabilis na access sa data. Ang repositoryo na nasa NFS ay madalas mas mahina kumpara sa repositoryo na nasa SSH sa parehong server, nagpapahintulot na ipagana ang Git gamit ang lokal na mga disk sa bawat sistema.

Sa wakas, hindi pinoprotektahan ng protokol na ito ang repositoryo mula sa mga hindi sinasadya na mga aksidente. Ang bawat gumagamit ay may buong access ng shell sa “remote” na direktoryo, at walang pumipigil sa kanila sa pagbago o pagtanggal ng mga Git files sa loob at pag-corrupt sa repositoryo.

Ang Smart HTTP ay gumagana katulad ng mga protokol ng SSH o Git pero gumagana sa mga standard na port ng HTTPS at makakagamit ng iba’t ibang mekanismo ng pagpapatunay ng HTTP, ibig sabihin madalas na mas madali para sa gumagamit kaysa sa katulad ng SSH, dahil ikaw ang makakagamit ng mga bagay katulad ng pagpapatunay ng username/password kumpara sa pag-set up ng mga key ng SSH.

Marahil ay ito ng ang pinaka-popular na pamamaraan sa paggamit sa Git, dahil ito ay maaaring i-set up upang parehong maghatid ng hindi nagpapakilala katulad ng protokol ng git://, at maaaring i-push kasama ang pagpapatunay at encryption katulad ng protokol ng SSH. Sa halip ng pagkakaroon ng pag-set up ng iba’t ibang mga URL para sa mga ganitong bagay, maaaring gamitin ang isang URL para sa dalawa. Kapag susubukan mong mag-push at nangangailangan ng pag-awtentik ang repositoryo (na kung saan ito ay normal), Ang server ay maaaring mag prompt para sa isang username at password. Ito ay pareho para sa access sa pagbasa.

Sa katunayan, para sa mga serbisyo katulad ng GitHub,Ang URL na ginagamit mo upang tingnan ang repositoryo online (halimbawa, https://github.com/schacon/simplegit) ay parehong URL na maaari mong gamitin upang mag-clone at, kung ikaw ay may-access, mag-push.

Kapag ang server ay hindi tumugon ng isang matalinong serbisyo ng Git HTTP, Susubukan ng kliyente ng Git na bumalik sa mas madaling Dumb HTTP na protokol. Inaasahan ng Dumb na protokol ang hubad na repositoryo ng Git ang ihahatid tulad ng mga normal na mga file mula sa web server. Ang kagandahan ng Dumb HTTP ay ang madaling pag set-up nito. Sa totoo lang, ang kailangan mo lang gawin ay maglagay ng hubad na repositoryo ng Git sa ilalim ng isang HTTP na dokumento sa root at mag-set up ng isang tiyak na post-update hook, at tapos ka na (Tingnan Mga Hook ng Git). Sa puntong iyon, sinuman na makaka-access sa web server sa ilalim na kung saan maaaring ilagay ang repositoryo ay maaaring i-clone ang iyong repositoryo. Upang payagan ang access sa pagbasa sa iyong repositoryo sa HTTP, gumawa ng katulad nito:

Yun Lang. Ang post-update na hook na kasama ng Git bilang default ay ipinapagana ang tamang utos (git update-server-info) upang mapagana ng maayos ang HTTP fetching ang pag-kopya. Ang utos na ito ay pinapagana kapag nag-push ka sa repositoryo na ito (marahil sa SSH); pagktapos, maaaring mag-clone ang ibang tao gamit ang katulad

Sa partikular na kaso na ito, ginagamit natin ang /var/www/htdocs na landas na karaniwan sa mga Apache na setup, pero makikita mo na maaaring gumamit ng anumang statik na web server — ilagay lamang ang hubad na repositoryo sa kanyang landas. Ang data ng Git ay hinahatid bilang isang statik na mga file (tingnan ang Mga Panloob ng GIT na kabanata para sa mga detalye kung papaano ito eksaktong hinahatid).

Sa pangkalahatan pipili ka kung magpapagana ng pabasa/pagsulat na Smart HTTP server o ilagay na ma-access ang mga file bilang read-only sa Dumb na paraan. Bihirang magpagana ng halo ng dalawang serbisyo.

Tayo ay magtuon sa mga kalamangan ng Smart na bersyon ng HTTP na protokol.

Ang kasimplihan ng pagkakaroon ng isang URL para sa lahat ng klase ng access at pagkakaroon ng server na mag prompt lamang kapag kailangan ang pagpapatunay ay nagpapadali para sa mga end user. Ang kakayahan ng pag pagpapatunay gamit ang username at password ay isang malaking kalamangan sa SSH, dahil ang mga gumagamit ay hindi na kailangan lumikha sa lokal ng mga susi ng SSH at mag-upload ng kanilang pampubliko na susi sa server bago makikipag-ugnayan sa mga ito. Para sa mga hindi masyadong sopistikado na mga gumagamit, o mga gumagamit sa mga sistema kung saan hindi gaano karaniwan ang SSH, ito ay isang malaking kalamangan para sa kakayahang magamit. Ito rin ay isang napakabilis at mahusay na protokol, katulad ng SSH.

Maaari mo ring pagsilbihan ang iyong mga repositoryo bilang read-only sa HTTPS, ibig sabihin maaari mong i-encrypt ang paglipat ng nilalaman; o maaari mong gawin na gumamit ng mga tiyak na napirmahan na mga sertipiko ng SSL ang mga kliyente.

Isa pang magandang bagay ay ang HTTPS ay karaniwan na ginagamit na mga protokol na kung saan ang mga firewall ng mga korporasyon ay madalas na naka-set up para payagan ang trapiko sa mga port na ito.

Ang Git sa HTTPS ay maaaring maging mas nakakalito na i-set up kumpara sa SSH sa ibang mga server. Maliban dun, napakaliit ng kalamangan ang mayroon ang ibang mga protokol sa Smart HTTP para sa pagsilbi ng mga nilalaman ng Git.

Kung ikaw ny gumagamit ng HTTP para sa pagpapatunay ng pag-push, paminsan ang pagbibigay ng iyong mga kredensyal ay mas mahirap kaysa gumamit ng mga susi sa SSH. Gayunpaman, may mga iilang mga instrumento sa pag-cache ng kridensyal na maaari mong gamitin, kasali na ang Keychain access sa macOS at Tagapamahala ng Kredensyal sa Windows, upang gawin itong madali. Basahin ang Kredensyal na ImbakanCredential Storage upang makita kung papaano mag set up ng ligtas na pag-cache ng password sa iyong sistema.

Marami ang kalamangan ng paggamit ng SSH. Una, Ang SSH ay relatibong madali i-set up — Ang mga SSH daemon ay karaniwan, maraming mga network admin ang may karanasan gamit sila, at maraming distribusyon ng OS naka-set up kasama nila or mayroong mga kasangkapan upang pamahalaan sila. Sunod, ang pag-access sa SSH ay ligtas — lahat ng paglipat ng datos ay naka-encrypt at napatunayan. Sa wakas, katulad ng HTTPS, Git at mga lokal na protokol, ang SSH ay mabilis, ginagawang siksik ang datos bago nililipat.

Ang negatibong aspeto ng SSH ay ito ay hindi sumusuporta ng hindi kilalang pag-acces sa iyong Git na repositoryo. Kung ikaw ay gumagamit ng SSH, ang mga tao ay dapat may access sa SSH sa iyong makina, kahit na read-only lang ang kapasidad, na hindi gumagawa sa SSH na nakakatulong sa mga open source na proyekto para sa mga tao na gusto lamang i-clone ang iyong repositoryo at suriin ito. Kapag ginagamit mo lamang sa loob ng network ng iyong korporasyon, Maaaring ang SSH na protokol lamang ang iyong kailangan harapin. Kapag gusto mong payagan ang mga hindi kilalang read-only na access sa iyong mga proyekto at gusto rin gamitin ang SSH, kailangan mong mag-set up ng SSH para ikaw ay makaka-push pero iba pa para sa iba na mag-fetch.

Ang protokol ng Git ay kadalasan ang pinakamabilis na protokol sa paglipat sa network na magagamit. Kung ikaw ay naghahatid ng maraming trapiko sa isang pampublikong proyekto o naghahatid ng malaking proyekto na hindi nangangailangan ng pagpapatunay ng user para sa read na access, Malamang gugustohin mong mag set up ng isang Git daemon upang pagsilbihan ang iyong proyekto. Ito ay gumagamit ng parehong data-transfer na mekanismo sa protokol ng SSH pero walang encryption at pagpapatunay sa itaas.

Ang problema sa protokol ng Git ay ang kakulangan ng pagpapatunay. Ito ay sa pangkalahatan ay hindi gusto para sa protokol ng Git na maging tanging access sa iyong proyekto. Sa pangkalahatan, ipapares mo sa access ng SSH o HTTPS para sa iilang mga developer na mayroong push (sulat) na access at payagan ang iba na gamitin ang git:// para sa read-only na access. Ito rin siguro ang pinaka mahirap na i-set up na protokol. Ito ay dapat magpatakbo ng sariling daemon, na nangangailangan ng xinetd na pagsasaayos o ang katulad nito, na kung saan ay hindi palagi madaling gawin. Ito ay nangangailangan din ng access sa firewall patungo sa port 9418, na kung saan ay hindi kinikilala na port ng mga firewall ng korporasyon na parating payagan. Sa likod ng mga firewall ng korporasyon, itong nakatago na port ay karaniwang naka-block