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

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

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

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

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

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

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

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

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

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

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

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

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

Ќе се концентрираме на предностите на 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 се многу. Прво, SSH е релативно лесно да се постави - SSH демоните се вообичаени, многу мрежни администратори имаат искуство со нив, и многу дистрибуции на ОС се поставени со нив или имаат алатки за да управуваат со нив. Следно, пристапот до SSH е безбеден - целиот пренос на податоци е шифриран и автентичен. Последно, како и HTTPS, Git и локалните протоколи, SSH е ефикасна, правејќи ги податоците колку што е можно компактни пред да ја префрлат.

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

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

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