Git
Chapters ▾ 2nd Edition

4.1 Git sa Server - Ang Mga Protokol

Sa puntong ito, maaari mo na dapat gawin ang mga pang-araw-araw na gawain kung saan gagamitin mo ang Git. Gayunpaman, upang makagawa ng anumang kolaborasyon sa Git, kakailanganin mong magkaroon ng remote na respositoryo ng Git. Kahit na technically maaari mong i-push ang iyong mga pagbabago at i-push ang mga pagbabago mula sa mga repositoryo ng mga indibidwal, ang paggawa nito ay hindi hinihikayat dahil madali malito sa kanilang pinagtrabuhan kapag hindi ka maingat. At saka, gusto mo ma-access ang repositoryo ng mga tagapagtulong kahit offline ang iyong kompyuter — Ang pagkakaroon ng mas maaasahang pangkaraniwang repositoryo ay kadalasan kapaki-pakinabang. Sa gayon, ang ginusto na pamamaraan sa pakikipagtulungan ng may kasama ay ang pag-set up ng isang intermediate na repositoryo na kung saan may access kayong dalawa, at mag push at mag pull mula doon.

Ang pagpapatakbo ng isang Git Server ay tuwiran. Una, pipili ka kung anong mga protokol ang gusto mo gamitin ng iyong server sa pag-usap. Sinasaklaw ng unang bahagi ng kabanatang ito ang mga magagamit na mga protokol at ang mga kalamangan at kahinaan ng bawat isa. Ang mga susunod na mga bahagi ay magpapaliwanag sa ilang tipikal na mga set up na gamit ang mga protokol na iyon at kung papaano mapapatakbo ang iyong server gamit ang mga iyon. Sa wakas, tatalakayin natin ang ilang mga naka-host na opsyon, kapag wala kang pakialam na i-host ang iyong code sa server ng ibang tao at ayaw mong dumaan sa abala ng pag-set up at pagpapanatili ng sariling server.

Kapag hindi ka interesado sa pagpapatakbo ng sarili mong server, maaari kang lumaktaw sa huling bahagi ng kabanata upang makita ang ilang mga opsyon sa pag-set up ng isang naka-host na akawnt at pagkatapos ay lumipat sa susunod na kabanata, kung saan ay tatalakayin natin ang iba’t ibang ins at outs sa pagtatrabaho sa isang distributed source control environment.

Ang isang remote na repositoryo ay sa pangkalahatan ay isang hubad na repositoryo — isang repositoryo sa Git na walang gumagana na direktoryo. Dahil ang repositoryo ay ginagamit lamang bilang punto ng kolaborasyon, walang dahilan upang magkaroon ng snapshot na naka-check out sa disk; ito ay data ng Git lamang. Sa madaling salita, ang isang hubad na repositoryo ay naglalaman ng .git na direktoryo ng iyong proyekto at wala ng iba.

Ang Mga Protokol

Maaaring gamitin ng Git ang apat na magkakaibang mga protokol upang lumipat ng mga data: Lokal, HTTP, Secure Shell (SSH) at Git. Dito tatalakayin natin kung ano sila at kung saang mga pangunahing pangyayari gusto mo (o di gusto) sila gamitin.

Lokal na Protokol

Ang pinaka-pangunahin ay ang Lokal na protokol, na kung saan ang remote na repositoryo ay nasa ibang direktoryo sa parehong host. Madalas itong ginagamit kapag lahat kayo sa inyong koponan ay may access sa isang ibinahagi na filesystem tulad ng isang NFS mount, o sa malabong kaso na lahat ay nag-log sa parehong kompyuter. Ang huli ay hindi tamang-tama, kasi lahat ng instansya ng repositoryo ng iyong code ay naninirahan sa parehong kompyuter, mas malaki ang posibilidad ng pagkawala ng sakuna.

Kapag ikaw ay may isang ibinahagi na naka-mount na filesystem, maaari kang mag clone, mag-push sa, at mag pull mula sa isang lokal na nakabatay sa file na repositoryo. Para i-clone ang isang repositoryo na tulad nito, o idagdag bilang isang remote sa umiiral na proyekto, gamitin ang landas patungo sa repositoryo bilang URL. Halimbawa, upang i-clone ang isang lokal na repositoryo, maaari kang magpagana ng ganito:

$ git clone /srv/git/project.git

O maaari mong gawin ito:

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

Ang Git ay gumagana ng bahagyang maiba kapag tahasang tinukoy mo ang file:// sa simula ng URL. Kapag ang landas lamang ang tinukoy mo, Sinusubukan ng Git na gumamit ng mga hardlink o direktang kinokopya ang mga file na kailangan nito. Kapag tinukoy mo ang file://, pinapagana ng Git ang mga proseso na karanawing ginagamit upang lumipat ng data sa isang network, na kung saan ay karaniwang mas mahina. Ang pinakarason upang tukuyin ang file:// na prefix ay kung gusto mo ng isang malinis na kopya ng repositoryo na may mga reperensiya o mga object na naiwan — Sa pangkalahatan ay pagkatapos ng pag-import mula sa ibang VCS o sa isang bagay na katulad (tingnan Mga Panloob ng GIT para sa mga gawain ng pagpapanatili). Gagamitin natin ang normal na landas dito dahil ang paggawa nito ay halos parati na mas mabilis.

Upang magdagdag ng isang lokal na repositoryo sa umiiral na proyekto sa Git, maaari kang magpagana ng ganito:

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

Pagkatapos, maaaring i-push papunta o i-pull mula sa remote na iyon sa pamamagitan ng paggamit ng iyong bagong remote na pangalan local_proj parang ginagawa mo sa isang network.

Ang mga Kalamangan

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

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 mga Protokol ng HTTP

Ang Git ay maaaring makipag-usap sa HTTP gamit ang dalawang magkaibang mga mode. Bago ang Git 1.6.6, Mayroon lamang isang paraan upang maisagawa ito na kung saan ay madali at sa pangkalahatan ay read-only. Sa bersyon 1.6.6, isang bago, mas matalinong protokol ang ipinakilala na kasangkot ang Git na magagawang mas matalino na pag-usap ng paglipat ng data sa parehong paraan ng SSH. Sa mga nakaraang mga taon, itong bago na protokol ng HTTP ay naging popular dahil ito ay mas madali para sa gumagamit at mas matalino kung papaano nakikipag-usap. Ang mas bagong bersyon ay kadalasan mas tinutukoy bilang ang Smart HTTP na protokol at ang lumang paraan ay ang Dumb HTTP. Una natin tatalakayin ang mas bago na Smart HTTP protokol.

Smart HTTP

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.

Dumb HTTP

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:

$ 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

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

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

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.

Ang mga Kalamangan

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 mga Kahinaan

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.

Ang Protokol ng SSH

Ang isang karaniwang protokol ng paglilipat para sa Git kapag ang pag boto sa sarili ay nasa SSH. Ito ay dahil ang access ng SSH sa mga server ay naka-set up na sa karamihan ng mga lugar — at kapag wala pa, ito ay madaling gawin. Ang SSH ay isang protokol ng isang network na may pagpapatunay din at, dahil ito ay saanman, ito ay karaniwang madali i-set up at gamitin.

Upang i-clone ang isang repository ng Git sa SSH, maaari mong tukuyin ang isang ssh:// na URL tulad nito:

To clone a Git repository over SSH, you can specify an ssh:// URL like this:

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

O maari mong gamitin ang mas maikli na tulad ng scp na sintaks para sa protokol ng SSH:

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

Sa dalawang kaso sa itaas, kapag hindi mo tukuyin ang opsyonal na username, ipinapagpapalagay ng Git na ang user na kasalukuyang naka-log in.

Ang mga Kalamangan

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 mga Kahinaan

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

Ang sunod ay ang protokol ng Git. Ito ay isang espesyal na daemon na nakabalot sa Git, ito ay nakikinig sa isang dedikado na port (9418) na kung saan ay nagbibigay ng isang serbisyo tulad sa protokol ng SSH, pero walang pagpapatunay. Upang ang isang repositoryo ay magsilbi sa protokol ng Git, ikaw ay dapat lumikha ng isang git-daemon-export-ok na file — ang daemon ay hindi magsisilbi ng isang repositoryo kung walang file sa loob nito — pero maliban pa dun wala ng ibang seguridad. Ang alinman ang Git ng repositoryo ay magagamit ng lahat para i-clone, o hindi. Ibig sabihin karaniwang walang pag-push sa protokol na ito. Maaari mong paganahin ang access sa pag-push pero, dahil kulang ang pagpapatunay, sino man sa internet na mahahanap ang URL ng iyong proyekto ay maaaring mag-push sa proyektong iyon. Sapat na sabihin na ito ay bihira.

Ang mga Kalamangan

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 mga Kakulangan

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

scroll-to-top