Git 🌙
Chapters ▾ 2nd Edition

4.1 Server’də Git - Protokollar

Bu nöqtədə Git’i istifadə edəcəyiniz gündəlik vəzifələrin çoxunu edə bilməlisiniz. Bununla birlikdə, Git’də hər hansı bir əməkdaşlıq etmək üçün remote bir Git deposuna sahib olmalısınız. Dəyişiklikləri texniki cəhətdən push edə və fərdi depolardakı dəyişiklikləri pull edə bilsəniz də, diqqətli olmadığınız halda üzərində işlədiklərini kifayət qədər asanlıqla qarışdıra biləcəyiniz üçün bunu etmək məsləhət görülmür. Bundan əlavə, kompüteriniz oflayn olsa belə, əməkdaşlarınızın depoya daxil ola bilməsini istəyirsiniz - daha etibarlı ümumi bir deponun olması çox vaxt faydalıdır. Bu səbəbdən kimsə ilə əməkdaşlıq etmək üçün üstünlük verilən metod, hər ikinizin daxil ola biləcəyiniz bir aralıq depo qurmaq və buradan pull və push etməkdir.

Bir Git serverini idarə etmək olduqca sadədir. Əvvəlcə serverinizin hansı protokolları dəstəkləməsini istədiyinizi seçin. Bu fəslin birinci hissəsi mövcud protokolları və hər birinin müsbət və mənfi tərəflərini əhatə edəcəkdir. Növbəti hissələrdə bu protokollardan istifadə edərək bəzi tipik quraşdırma işləri və serverinizin onlarla necə işləməsini izah edəcəyik. Son olaraq kodunuzu başqasının serverində yerləşdirməyinizə qarşı çıxmasanız və öz serverinizi qurmaq və saxlamaq çətinliyindən keçmək istəmirsinizsə, bir neçə yerləşdirilmiş seçimdən keçəcəyik.

Öz serverinizi idarə etməklə maraqlanmırsınızsa, yerləşdirilmiş bir hesab qurmaq üçün bəzi variantları görmək üçün bölmənin son hissəsinə keçib paylanmış mənbə nəzarəti mühitində işin müxtəlif müsbət və mənfi tərəflərini müzakirə etdiyimiz növbəti hissəyə keçə bilərsiniz.

Remote bir depo ümumiyyətlə bir işləmə qovluğu olmayan bir Git deposu olan bir bare deposu-dur. Depo yalnız bir işləmə nöqtəsi olaraq istifadə olunduğundan, bir snapshot-u diskdə yoxlamaq üçün heç bir səbəb yoxdur; yalnız Git məlumatlarıdır. Ən sadə dildə desək, bare bir depo, layihənizin .git qovluğunun məzmunudur və başqa heç nə deyildir.

Protokollar

Git məlumat ötürmək üçün dörd fərqli protokoldan istifadə edə bilər: Local, HTTP, Secure Shell (SSH) və Git. Burada bunların nə olduğunu və hansı əsas şərtlərdə istifadə etməyinizi (və ya istəmədiyinizi) müzakirə edəcəyik.

Local Protokol

Ən əsası uzaq depo ilə eyni hostdakı başqa bir qovluqda olan Local protocol -dur. Bu, komandanızdakı hər kəsin bir NFS quraşdırılmış bir fayl sisteminə çıxışı olduqda və ya hamının eyni kompüterə girməsi ehtimalı az olduqda istifadə olunur. Sonuncu ideal olmazdı, çünki bütün kod depo instansiyaları eyni kompüterdə yerləşəcək və fəlakətli itkini daha çox edə bilər.

Birgə quraşdırılmış bir fayl sisteminiz varsa, local bir sənəd əsaslı depo ilə klonlaşa, pus və pull edə bilərsiniz. Bu kimi bir depo klonlaşdırmaq və ya mövcud bir layihəyə uzaqdan bir əlavə etmək üçün URL olaraq depo path-dan istifadə edin. Məsələn, local bir depo klonlaşdırmaq üçün belə bir şey işlədə bilərsiniz:

$ git clone /srv/git/project.git

Or you can do this:

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

URL’in əvvəlində file://-nı dəqiq göstərsəniz, Git bir qədər fərqli işləyər. Yalnız path-ı göstərsəniz, Git sərt keçidlərdən istifadə etməyə və ya lazım olan sənədləri birbaşa kopyalamağa çalışar. file:// yazsanız, Git ümumiyyətlə çox az səmərəli olan bir şəbəkə üzərindən məlumat ötürmək üçün istifadə etdiyi prosesləri başladar. file:// prefiksinin göstərilməsinin əsas səbəbi, başqa bir VNS və ya buna bənzər bir şeyin idxalından sonra deponun lazımsız istinadlar və ya obyektlər xaric təmiz kopyasını istəməyinizdir.(Baxım işləri üçün Git’in Daxili İşləri-a baxın).

Burada normal yoldan istifadə edəcəyik, çünki bunu etmək demək olar ki, həmişə daha sürətli olur.

Mövcud Git layihəsinə local bir depo əlavə etmək üçün belə bir şey işlədə bilərsiniz:

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

Daha sonra yeni bir uzaq adınızı local_proj vasitəsilə uzaqdan push və pull edə bilərsiniz.

Üstünlüklər

Fayl əsaslı depoların üstünlükləri sadə olduqları və mövcud fayl icazələrindən və şəbəkə girişlərindən istifadə etmələridir. Bütün qrupunuzun daxil olduğu ortaq bir fayl sisteminiz varsa, depo qurmaq çox asandır. Çılpaq depo nüsxəsini hər kəsin paylaşdığı bir yerə yapışdırırsınız və hər hansı digər paylaşılan qovluq üçün olduğu kimi oxumaq/yazma icazələrini təyin edirsiniz. Bunun üçün Serverdə Git Əldə Etmək-də çılpaq bir depo kopyasını necə ixrac edəcəyimizi müzakirə edəcəyik.

Başqasının işlədiyi depo-dan tez bir zamanda iş aparmaq üçün bu da əlverişli bir seçimdir. Bir iş yoldaşınızla eyni layihə üzərində işləsəniz və bir şeyin yoxlanılmasını istəsəniz, git pull /home/john/project kimi bir əmr işlətmək uzaq bir serverə pushing edib və sonradan fetching etməkdən daha asandır.

Çatızmazlıqları

Bu metodun mənfi cəhətləri budur ki, paylaşılan girişin qurulmasının və birdən çox yerdən əsas şəbəkə girişinin ümumiyyətlə daha çətin olmasıdır. Evdə olduğunuz zaman dizüstü kompüterinizdən push etmək istəsəniz, şəbəkə əsaslı girişlə müqayisədə çətin və yavaş ola bilən uzaq disk quraşdırmalısınız.

Bir növ ortaq bir montajdan istifadə edirsinizsə, bu mütləq ən sürətli seçim olmadığını qeyd etmək vacibdir. Local bir depo yalnız məlumatlara sürətli çıxışınız olduqda sürətli olur. NFS-də bir depo eyni serverdəki SSH üzərindəki depozitdən daha yavaş olur, bu da Git-in hər sistemdəki yerli diskləri işə salmasına imkan verir.

Nəhayət, bu protokol depo-nu təsadüfi zərərdən qoruyur. Hər bir istifadəçinin “uzaqdan” qovluğuna tam shell çıxışı var və onların daxili Git fayllarını dəyişdirməsinə və ya silinməsinə və depo-nun korlanmasına mane olan heç bir şey yoxdur.

HTTP Protokolları

Git iki fərqli rejimi istifadə edərək HTTP ilə əlaqə qura bilər. Git 1.6.6-dan əvvəl bunun sadə və ümumiyyətlə sadəcə oxumaq üçün edə biləcəyi bir yolu var idi. 1.6.6 versiyasında Git-in SSH üzərində olduğu kimi bir şəkildə məlumat ötürmə danışıqlarını daha ağıllıca edə bilməsi ilə əlaqəli yeni, daha asan və daha ağıllı bir protokol təqdim edildi. Son bir neçə ildə bu yeni HTTP protokolu istifadəçi və ünsiyyət qurma qaydaları haqqında daha sadə və ağıllı olduğu üçün çox məşhur oldu. Daha yeni versiyaya ümumiyyətlə Smart HTTP protokolu ve daha köhnə olana Dumb HTTP denir. Əvvəlcə daha yeni Smart HTTP protokolunu incəliyəcəyik.

Smart HTTP

Smart HTTP, SSH və ya Git protokollarına bənzər şəkildə işləyir, lakin standart HTTPS portları üzərində işləyir və müxtəlif HTTP identifikasiya mexanizmlərindən istifadə edə bilir. Bu o deməkdir ki, SSH keys-i quraşdırmaq yerinə istifadəçi adı/parol identifikasiyası kimi şeylərdən istifadə edə biləcəyiniz üçün istifadəçi üçün SSH kimi bir şeydən daha asan olduğu anlamına gəlir.

Yəqin ki, Git istifadə etmək üçün ən populyar bir yol halına gəlmişdir, çünki həm anonim olaraq git:// protokolu kimi xidmət edəcək şəkildə istifadə edilə bilər, həm də SSH protokolu kimi identifikasiya və şifrələmə ilə ötürülə bilər. Bu şeylər üçün fərqli URL-lər qurmaq əvəzinə indi hər ikisi üçün tək bir URL istifadə edə bilərsiniz. Əgər push etməyə cəhd etsəniz və depo doğrulamasını (adətən olmalıdır) tələb edirsə, server istifadəçi adı və şifrə tələb edə bilər. Oxuma girişi üçün də eyni şey keçərlidir.

Əslində, GitHub kimi xidmətlər üçün depo-nu onlayn olaraq görüntüləmək üçün istifadə etdiyiniz URL (məsələn, https://github.com/schacon/simplegit) klonlaşdırmaq üçün istifadə edə biləcəyiniz URL-dir və əgər daxil ola bilirsinizsə, push over edin.

Dumb HTTP

Server Git HTTP ağıllı xidməti ilə cavab vermirsə, Git müştəri daha sadə Dumb HTTP protokoluna geri dönməyə çalışacaq. Dumb protokolu çılpaq Git depolarının veb serverdən normal fayllar kimi təqdim olunmasını gözləyir. Dumb HTTP-nin gözəlliyi onu qurmağın sadəliyidir. Əsasən, HTTP sənəd root-nuzun altına çılpaq Git depoziti qoymalı və konkret bir post-update hook qurmağınız kifayətdir(Git Hook’ları-a baxın). Bu zaman depo qoyduğunuz veb serverə daxil ola bilən hər kəs deponuzu klonlaya bilər. HTTP üzərindəki depo yerinə oxunuşa icazə vermək üçün belə bir şey edin:

$ 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

Bu qədər. Default olaraq Git ilə birlikdə gələn post-update hook, HTTP-nin alınması və klonlanmasının düzgün qurulması üçün müvafiq əmr (git update-server-info) işlədir. Bu əmr bu deponu (SSH-dən çox) push etdikdə yerinə yetirilir; sonra digər insanlar da klonlaya bilər:

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

Bu vəziyyətdə, Apache tənzimləmələri üçün ümumi olan /var/www/htdocs yolunu istifadə edirik, ancaq hər hansı bir statik veb serverdən istifadə edə bilərsiniz - bu path-a sadəcə çılpaq depoları qoyun. Git məlumatları əsas statik sənədlər kimi təqdim olunur (xidmətin necə aparıldığı barədə ətraflı məlumat üçün Git’in Daxili İşləri-a baxın).

Ümumiyyətlə, Smart HTTP serverini oxumaq/yazmaq və ya sadəcə Dumb şəkildə sadəcə oxunan kimi əlçatan faylları seçməyi seçərdiniz. İki xidmətin qarışığını işlətmək nadirdir.

Üstünlüklər

HTTP protokolunun Smart versiyasının üstünlüklərini cəmləşdirəcəyik.

Hər cür giriş üçün vahid bir URL-yə sahib olmağın və serverinin yalnız identifikasiya lazım olduqda istəməsinin olması sadəliyi son istifadəçi üçün işləri çox asanlaşdırır. Bir istifadəçi adı və şifrə ilə identifikasiya edə bilməyiniz SSH-a da böyük bir üstünlükdür, çünki istifadəçilər local SSH key-lərini yarada və açıq key-ləri serverə yükləmək lazım deyil. Daha az inkişaf etmiş istifadəçilər və ya SSH-nin daha az yayıldığı sistemlərdəki istifadəçilər üçün bu əsas üstünlükdür. Həm də SSH protokoluna bənzər çox sürətli və səmərəli bir protokoldur.

Ayrıca depolarınıza HTTPS üzərində yalnız oxuya bilərsiniz, yəni məzmun ötürməsini şifrələyə bilərsiniz; və ya müştərilərin xüsusi imzalı SSL sertifikatlarından istifadə etmələri üçün bu qədər irəliyə gedə bilərsiniz.

Başqa bir xoş bir şey, HTTP və HTTPS bu qədər istifadə olunan protokollardır ki, korporativ firewal-lar tez-tez portları üzərindən trafikə icazə vermək üçün qurulur.

Çatızmazlıqları

HTTPS üzərindən Git bəzi serverlərdə SSH ilə müqayisədə bir az daha çətin ola bilər. Bundan başqa, digər protokolların Git məzmununa xidmət üçün Smart HTTP-ə görə üstünlüyü çox azdır.

Kimliği təsdiq edilmiş pushing üçün HTTP istifadə edirsinizsə, kimlik məlumatlarınızı təmin etmək bəzən SSH üzərindəki key-lərədən istifadə etməkdən daha mürəkkəbdir. Bununla birlikdə, bu, MacOS-da Keychain access-i və Windows-da Credential Manager kimi olduqca ağrısız hala gətirmək üçün istifadə edə biləcəyiniz bir neçə credential caching vasitəsi var. Sisteminizdə təhlükəsiz HTTP şifrələməsini necə qurulacağını görmək üçün Etibarlı Yaddaş oxuyun.

SSH Protokolu

Self-hosting SSH üzərində olanda Git üçün ümumi transport protokolu. Bunun səbəbi, serverlərə SSH girişi artıq əksər yerlərdə qurulmuşdur - əgər olmursa, bunu etmək asandır. SSH eyni zamanda təsdiq edilmiş bir şəbəkə protokoludur və local olduğundan ümumiyyətlə qurmaq və istifadə etmək asandır.

Bir Git depozitini SSH üzərində klonlaşdırmaq üçün `ssh:// URL-i kimi göstərə bilərsiniz:

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

Və ya SSH protokolu üçün daha qısa scp kimi sintaksisdən istifadə edə bilərsiniz:

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

Yuxarıdakı hər iki halda əlavə istifadəçi adını göstərməmisinizsə, Git hazırda daxil olduğunuz istifadəçini qəbul edəcəkdir.

Üstünlükləri

SSH istifadə üstünlükləri çoxdur. Birincisi, SSH qurmaq nisbətən asandır - SSH daemonları adi haldır, bir çox şəbəkə rəhbərləri onlarla təcrübəyə malikdirlər və bir çox OS paylamaları onlarla qurulur və ya onları idarə etmək üçün vasitələr var. Sonra SSH üzərindən giriş etibarlıdır - bütün məlumat ötürülməsi şifrələnmiş və təsdiq edilmişdir. Sonuncu, HTTPS, Git və Local protokollar kimi SSH səmərəlidir, ötürülmədən əvvəl məlumatları mümkün qədər yığcam edir.

Çatızmazlıqları

SSH-in mənfi tərəfi, Git depozitinizə anonim girişi dəstəkləməməsidir. SSH istifadə edirsinizsə, insanların çoxu yalnız oxumaq qabiliyyətində olsa da SSH-nin maşınlarınıza SSH girişi əldə edə bilər, bu da insanların araşdırmaq üçün depozitlərinizi klonlaşdırmaq istədikləri açıq mənbəli layihələri SSH üçün əlverişli etmir. Bunu yalnız korporativ şəbəkənizdə istifadə edirsinizsə, SSH ilə əlaqəli olduğunuz yeganə protokol ola bilər. Layihələrinizə anonim oxunuşlu giriş imkanı vermək və həmçinin SSH-dən istifadə etmək istəyirsinizsə, SSH-ı təkan verməyiniz üçün başqalarından almaq üçün başqa bir şey qurmalı olacaqsınız.

Git Protokolu

Nəhayət, Git protokolumuz var. Bu Git ilə birliktə gələn xüsusi bir daemon-dur; SSH protokoluna bənzər bir xidmət təqdim edən xüsusi bir portda (9418) dinləyir, lakin tamamilə təsdiqlənməsi yoxdur. Git protokolu üzərində depo xidmətinin göstərilməsi üçün bir git-daemon-export-ok faylı yaratmalısınız - daemon bu sənəd olmadan depoya xidmət göstərməyəcək - ancaq bundan başqa təhlükəsizlik yoxdur. Hər kəsin klonlaşması üçün Git depoziti mövcuddur, ya da yoxdur. Bu o deməkdir ki, ümumiyyətlə bu protokola push etmək olmur. Push access-i aktivləşdirə bilərsiniz, ancaq identifikasiyanın olmaması halında, İnternetdə layihənizin URL-ini tapan hər kəs bu layihəyə push edə bilər. Bunun nadir olduğunu söyləmək kifayətdir.

Üstünlükləri

Git protokolu tez-tez mövcud olan ən sürətli şəbəkə ötürmə protokoludur. Bir ictimai layihə üçün bir çox trafikə xidmət edirsinizsə və ya oxumaq üçün istifadəçi identifikasiyasını tələb etməyən çox böyük bir layihəyə xidmət edirsinizsə, ehtimal ki, proyektinizə xidmət etmək üçün Git daemon qurmaq istəyə bilərsiniz. Şifrələmə və autentifikasiya olmadan SSH protokolu ilə eyni məlumat ötürmə mexanizmini istifadə edir.

Çatışmazlıqları

Git protokolunun mənfi tərəfi identifikasiyanın olmamasıdır. Git protokolunun layihənizə yeganə giriş olması ümumiyyətlə arzuolunmazdır. Ümumiyyətlə, push (yazma) girişi olan və hər kəsin yalnız oxumaq üçün istifadə etdiyi git:// istifadə edən bir neçə developer üçün SSH və ya HTTPS ilə uyğunlaşdıracaqsınız. Yəqin ki, qurmaq üçün ən çətin protokoldur. xinetd və ya systemd konfiqurasiyasını və ya bənzərliyini tələb edən öz daemini işlətməlidir, bu da həmişə parkda gəzmək deyil. Həm də korporativ firewall-ların həmişə icazə verdiyi standart bir port olmayan 9418 portuna firewall girişi tələb olunur. Böyük korporativ firewall-ların arxasında bu qaranlıq port ümumiyyətlə bloklanır.

scroll-to-top