Git 🌙
Chapters ▾ 2nd Edition

4.1 Git на Сервер - Протоколите

Во овој момент, треба да бидете во можност да ги направите повеќето од секојдневните задачи за кои ќе го користите Git. Сепак, за да направите било каква соработка во Git, ќе треба да имате далечинско складиште за Git. Иако технички може да ги притиснете промените и да ги повлечете промените од складиштата на поединци, тоа е обесхрабрено затоа што лесно може да се збуни она што тие го работат ако не сте внимателни. Понатаму, сакате вашите соработници да можат да пристапат до складиштето, дури и ако вашиот компјутер не е присутен - честопати е корисно да има посигурно заедничко складиште. Затоа, преферираниот метод за соработка со некого е да поставите средно складиште на кое и двајцата ќе имате пристап и да притиснете и да се повлечете од тоа.

Извршувањето на Git серверот е прилично јасна. Прво, ќе одберете кои протоколи сакате вашиот сервер да комуницира. Првиот дел од ова поглавје ќе ги опфати достапните протоколи и предностите и негативностите на секоја од нив. Следните делови ќе објаснат некои типични поставувања со користење на овие протоколи и како да го стартувате вашиот сервер со нив. Последно, ние ќе одиме преку неколку домаќини опции, ако не ви пречи хостинг вашиот код на некој друг сервер и не сакаат да одат преку кавга за поставување и одржување на вашиот сопствен сервер.

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

Оддалеченото складиште обично е баре складиште - репозиториум на Git кој нема работен директориум. Бидејќи складиштето се користи само како точка за соработка, нема причина да се провери снимката на дискот; тоа е само податоците на Git. Во наједноставните термини, голиот репозиториум е содржината на директориумот .git на вашиот проект и ништо друго.

Протоколите

Git може да користи четири различни протоколи за пренос на податоци: Local, HTTP, Secure Shell (SSH) и Git. Овде ќе разговараме за она што се и во кои основни околности сакате (или не сакате) да ги користите.

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

Најосновниот е Local protocol, во кој оддалеченото складиште е во друг директориум на истиот хост. Ова често се користи ако секој од вашиот тим има пристап до заеднички датотечен систем, како што е NFS монтирање, или во помалку веројатно дека сите се најавуваат на ист компјутер. Вторите нема да бидат идеални, бидејќи сите случаи за складиште на код ќе живеат на ист компјутер, што ќе направи многу поголема веројатност за катастрофална загуба.

Ако имате заеднички монтиран датотечен систем, тогаш можете да клонирате, притиснете и повлечете од локално складиште засновано на датотеки. За да го клонирате ова складиште како ова, или да го додадете како далечински во постоечки проект, користете ја патеката до складиштето како URL. На пример, за да клонирате локално складиште, може да стартувате нешто слично:

$ git clone /srv/git/project.git

Или можете да го направите ова:

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

Git работи малку поинаку ако експлицитно наведете file: // на почетокот на URL-то. Ако едноставно ја наведете патеката, Git се обидува да користи тврдини или директно да ги копира потребните датотеки. Ако наведете file: //, Git ги активира процесите што вообичаено ги користи за пренос на податоци преку мрежа, што обично е многу помалку ефикасно. Главната причина да го наведете префиксот file: // е ако сакате чиста копија од складиштето со надворешни референци или предмети изоставени - обично по увоз од друг VCS или нешто слично (види << ch10-git-internals >> за задачи за одржување). Ние ќе го користиме нормалниот пат тука, бидејќи тоа е скоро секогаш побрзо.

За да додадете локално складиште во постоечки проект Git, може да стартувате нешто слично:

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

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

The Pros

Предностите на архивите базирани на датотеки се дека тие се едноставни и тие ги користат постоечките дозволи за датотеки и мрежен пристап. Ако веќе имате заеднички датотечен систем на кој целиот свој тим има пристап, поставувањето на складиштето е многу лесно. Вие ставате копија на голиот складиште некаде каде што сите имаат пристап до и ги поставуваат дозволите за читање / запишување како и за било кој друг споделен именик. Ќе разговараме за тоа како да извезете копија за горенаведеното складиште за оваа намена во << _getting_git_on_a_server >>.

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

Конс

Маските на овој метод се дека заедничкиот пристап е генерално потешко да се постави и да се достигне од повеќе локации од основниот мрежен пристап. Ако сакате да притиснете од вашиот лаптоп кога сте дома, треба да го монтирате далечинскиот диск, кој може да биде тежок и бавен во споредба со мрежниот пристап.

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

Конечно, овој протокол не го заштитува складиштето од случајна штета. Секој корисник има целосен пристап до школка до "далечинскиот" директориум, и нема ништо што ги спречува да ги менуваат или отстрануваат внатрешните Git датотеки и го оштетуваат складиштето.

HTTP протоколите

Git може да комуницира преку HTTP користејќи два различни режими. Пред Git 1.6.6, постоеше само еден начин што можеше да го стори тоа што беше многу едноставно и главно само за читање. Во верзијата 1.6.6 беше воведен нов, попаметен протокол кој вклучуваше Git да може интелигентно да преговара за пренос на податоци на начин сличен на тоа како го прави преку SSH. Во последните неколку години, овој нов HTTP протокол стана многу популарен бидејќи е поедноставен за корисникот и попаметно за тоа како комуницира. Поновите верзии често се нарекуваат протокол Smart HTTP и постариот начин како Dumb HTTP. Прво ќе го покриеме новиот Smart HTTP протокол.

Smart HTTP

Smart HTTP работи многу слично на SSH или Git протоколите, но работи преку стандардни HTTPS порти и може да користи разни механизми за HTTP автентикација, што значи дека е често полесно за корисникот отколку нешто како SSH, бидејќи можете да ги користите нештата како идентификација на корисничко име / лозинка, наместо за да поставите SSH клучеви.

Веројатно стана најпопуларен начин да се користи Git сега, бидејќи може да се постави за да служат како анонимно како протокол git: //, а исто така може да се турка со автентикација и енкрипција како SSH протоколот. Наместо да поставите различни URL адреси за овие работи, сега можете да користите еден URL за двете. Ако се обидете да притиснете и за складиштето потребно е автентикација (што вообичаено треба да биде), серверот може да побара корисничко име и лозинка. Истото важи и за пристап за читање.

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

Глупо HTTP

Доколку серверот не реагира со паметна услуга Git HTTP, клиентот Git ќе се обиде да се врати на поедноставниот Dumb HTTP протокол. Глуповиот протокол очекува дека голиот репозиториум на Git ќе се служи како нормални датотеки од веб серверот. Убавината на Глупо HTTP е едноставноста на поставување. Во суштина, се што треба да направите е да го ставите готното складиште на Git под root HTTP документот и да поставите специфична кука за пост-ажурирање и да завршите (види << _git_hooks >>). Во тој момент, секој што може да пристапи на веб-серверот под кој го ставате складиштето, исто така, може да клонира вашето складиште. За да дозволите читање пристап до вашето складиште преку 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

Тоа е сè. Куката "по ажурирање" која потекнува со Git стандардно ја извршува соодветната команда (git update-server-info) за правилно преземање и клонирање на HTTP. Оваа команда се извршува кога ќе притиснете на ова складиште (можеби преку SSH); тогаш, други луѓе можат да клонираат преку нешто слично

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

Во овој конкретен случај, ние ја користиме патеката / var / www / htdocs која е честа за поставувањата на Apache, но можете да користите било кој статичен веб сервер - само ставете го голиот репозиториум на патеката. Податоците на Git се служат како основни статички датотеки (видете го поглавјето << ch10-git-internals >> за детали околу тоа како точно се служи).

Општо земено, вие би можеле да одберете да извршите читање / запишување на Smart HTTP сервер или едноставно да ги имате пристапните датотеки како само за читање на глупавиот начин. Ретко е да се води мешавина од двете услуги.

The Pros

Ќе се концентрираме на предностите на Smart верзија на HTTP протоколот.

Едноставноста да се има единствен УРЛ за сите типови на пристап и да има потсетник на серверот само кога е потребна проверка на автентичност, ги прави работите многу лесни за крајниот корисник. Да се ​​биде во можност да се идентификувате со корисничко име и лозинка исто така е голема предност над SSH, бидејќи корисниците не мора локално да генерираат SSH клучеви и да го стават својот јавен клуч на серверот пред да можат да комуницираат со него. За помалку софистицирани корисници или корисници на системи каде SSH е поретко, ова е голема предност во употребливоста. Исто така, тоа е многу брз и ефикасен протокол, сличен на SSH.

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

Уште една убава работа е дека HTTPS се такви најчесто користени протоколи дека корпоративните firewalls често се поставуваат за да овозможат сообраќај преку овие порти.

Конс

Git преку HTTPS може да биде малку потешко да се постави во споредба со SSH на некои сервери. Освен тоа, има многу малку предност што другите протоколи имаат над Smart HTTP за сервирање на Git содржина.

Ако користите HTTP за автентично притискање, обезбедувањето на вашите ингеренции понекогаш е покомплицирано од користење на копчињата преку SSH. Меѓутоа, постојат неколку алатки за кеширање кои можете да ги користите, вклучувајќи го пристапот на Keychain во MacOS и Credential Manager во Windows, за да го направите ова прилично безболно. Прочитајте << _credential_caching >> за да видите како да поставите безбедно кеширање на HTTP лозинка на вашиот систем.

протокол за SSH

Заеднички протокол за транспорт за Git кога само-хостинг е над SSH. Тоа е затоа што SSH пристапот до сервери е веќе поставена на повеќето места - и ако не е, тоа е лесно да се направи. SSH е, исто така, автентичен мрежен протокол и, бидејќи е сеприсутен, обично е лесно да се постави и да се користи.

За да го клонирате репозиториумот Git преку SSH, можете да наведете ssh: // URL вака:

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

Или можете да ја користите пократката SCP како синтакса за SSH протоколот:

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

Во двата случаи погоре, ако не го наведете општото корисничко име, Git го презема корисникот на кој сте моментално најавени.

The Pros

Предностите на користење на SSH се многу. Прво, SSH е релативно лесно да се постави - SSH демоните се вообичаени, многу мрежни администратори имаат искуство со нив, и многу дистрибуции на ОС се поставени со нив или имаат алатки за да управуваат со нив. Следно, пристапот до SSH е безбеден - целиот пренос на податоци е шифриран и автентичен. Последно, како и HTTPS, Git и локалните протоколи, SSH е ефикасна, правејќи ги податоците колку што е можно компактни пред да ја префрлат.

Конс

Негативниот аспект на SSH е тоа што не поддржува анонимни пристап до вашиот Git репозиториум. Ако користите SSH, луѓето must имаат SSH пристап до вашата машина, дури и со капацитет за читање, што не го прави SSH погоден за проекти со отворен код за кои луѓето едноставно би сакале да го клонираат вашето складиште за да го испитаат. Ако го користите само во вашата корпоративна мрежа, SSH може да биде единствениот протокол со кој треба да се справите. Ако сакате да дозволите анонимни пристап само за читање на вашите проекти, а исто така сакате да користите SSH, ќе треба да поставите SSH за да можете да ги пренасочите, но нешто друго за другите да дојдат од.

The Git Protocol

Next is the Git protocol. Ова е посебен демон кој доаѓа спакуван со Git; слуша на посветена порта (9418) која обезбедува услуга слична на SSH протоколот, но со апсолутно никаква автентикација. За да може складиштето да се сервира преку протоколот Git, мора да креирате датотека git-daemon-export-ok - демон не ќе му служи на складиштето без таа датотека во неа - но освен тоа постои нема безбедност. Или репозиториумот Git е достапен за сите да клонираат, или не. Ова значи дека генерално нема туркање над овој протокол. Можете да овозможите пристап до притискање, но, со оглед на недостатокот на автентикација, секој на интернет кој го наоѓа URL-то на вашиот проект може да изврши притисок врз тој проект. Доволно е да се каже дека ова е ретко.

The Pros

Протоколот Git е најбрз протокол за мрежен пренос. Ако сервирате многу сообраќај за јавен проект или служат многу голем проект кој не бара идентификација на корисникот за пристап за читање, веројатно е дека ќе сакате да поставите демон Git за да му служат на вашиот проект. Таа го користи истиот механизам за пренос на податоци како протокол за SSH, но без енкрипција и автентикација над глава.

Конс

Недостатоци на протоколот Git е недостатокот на автентикација. Тоа е генерално непожелно за протоколот Git да биде единствениот пристап до вашиот проект. Општо земено, ќе го спарите со SSH или HTTPS пристап за неколку програмери кои имаат притисни (запишување) пристап и сите други ги користат "git: //" за пристап за читање. Исто така, веројатно е најтешкиот протокол за поставување. Мора да го води својот сопствен демон, кој бара xinetd конфигурација или слично, што не е секогаш прошетка во паркот. Таа, исто така, бара пристап до огнениот ѕид до портата 9418, што не е стандардна порта која корпоративните firewalls секогаш дозволуваат. Зад големите корпоративни заштитни ѕидови, ова прикриено пристаниште најчесто е блокирано.

scroll-to-top