-
1. Başlanğıc
- 1.1 Versiyaya Nəzarət Haqqında
- 1.2 Git’in Qısa Hekayəsi
- 1.3 Git Nədir?
- 1.4 Əmr Sətiri
- 1.5 Git’i Quraşdırmaq
- 1.6 İlk Dəfə Git Quraşdırması
- 1.7 Kömək Almaq
- 1.8 Qısa Məzmun
-
2. Git’in Əsasları
-
3. Git’də Branch
- 3.1 Nutshell’də Branch’lar
- 3.2 Sadə Branching və Birləşdirmə
- 3.3 Branch İdarəedilməsi
- 3.4 Branching İş Axınları
- 3.5 Uzaq Branch’lar
- 3.6 Rebasing
- 3.7 Qısa Məzmun
-
4. Server’də Git
- 4.1 Protokollar
- 4.2 Serverdə Git Əldə Etmək
- 4.3 Sizin öz SSH Public Key’nizi yaratmaq
- 4.4 Server qurmaq
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Üçüncü Tərəf Seçimləri
- 4.10 Qısa Məzmun
-
5. Paylanmış Git
-
6. GitHub
-
7. Git Alətləri
- 7.1 Reviziya Seçimi
- 7.2 Interaktiv Səhnələşdirmə
- 7.3 Stashing və Təmizləmə
- 7.4 İşinizin İmzalanması
- 7.5 Axtarış
- 7.6 Tarixi Yenidən Yazmaq
- 7.7 Reset Demystified
- 7.8 İnkişaf etmiş Birləşmə
- 7.9 Rerere
- 7.10 Git ilə Debugging
- 7.11 Alt Modullar
- 7.12 Bundling
- 7.13 Dəyişdirmək
- 7.14 Etibarlı Yaddaş
- 7.15 Qısa Məzmun
-
8. Git’i Fərdiləşdirmək
- 8.1 Git Konfiqurasiyası
- 8.2 Git Atributları
- 8.3 Git Hook’ları
- 8.4 Git-Enforced Siyasət Nümunəsi
- 8.5 Qısa Məzmun
-
9. Git və Digər Sistemlər
- 9.1 Git Müştəri kimi
- 9.2 Git’ə Miqrasiya
- 9.3 Qısa Məzmun
-
10. Git’in Daxili İşləri
- 10.1 Plumbing və Porcelain
- 10.2 Git Obyektləri
- 10.3 Git Referansları
- 10.4 Packfile’lar
- 10.5 Refspec
- 10.6 Transfer Protokolları
- 10.7 Maintenance və Məlumatların Bərpası
- 10.8 Mühit Dəyişənləri
- 10.9 Qısa Məzmun
-
A1. Appendix A: Digər Mühitlərdə Git
- A1.1 Qrafik interfeyslər
- A1.2 Visual Studio’da Git
- A1.3 Visual Studio Code’da Git
- A1.4 Eclipse’də Git
- A1.5 Sublime Text’də Git
- A1.6 Bash’da Git
- A1.7 Zsh’də Git
- A1.8 PowerShell’də Git
- A1.9 Qısa Məzmun
-
A2. Appendix B: Proqramlara Git Daxil Etmək
- A2.1 Əmr-sətri Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Appendix C: Git Əmrləri
- A3.1 Quraşdırma və Konfiqurasiya
- A3.2 Layihələrin Alınması və Yaradılması
- A3.3 Sadə Snapshotting
- A3.4 Branching və Birləşmə
- A3.5 Layihələrin Paylaşılması və Yenilənməsi
- A3.6 Yoxlama və Müqayisə
- A3.7 Debugging
- A3.8 Patching
- A3.9 E-poçt
- A3.10 Xarici Sistemlər
- A3.11 İdarəetmə
- A3.12 Plumbing Əmrləri
5.1 Paylanmış Git - Distribyutorluq İş Axınları
Artıq bütün developer’lərin kodlarını paylaşması üçün mərkəz nöqtəsi olaraq qurulmuş remote bir Git deposuna sahib olduğunuzdan və lokal iş axınındakı əsas Git əmrləri ilə tanış olduğunuza görə bəzi paylanmış iş axınlarından necə istifadə edəcəyinizə baxacaqsınız.
Bu fəsildə paylayıcı və inteqrasiyaedici olaraq paylanmış bir mühitdə Git ilə necə işləməli olduğunuzu görəcəksiniz. Yəni bir layihəyə uğurla kod əlavə etməyi və onu və layihə qoruyucusunu mümkün qədər asanlaşdırmağı və bir sıra developer’lərlə layihəni necə uğurla davam etdirməyi öyrənəcəksiniz.
Distribyutorluq İş Axınları
Centralized Version Control Systems (CVCS)'dən fərqli olaraq distribyutor xarakterli Git sizə developerlərin proyektlərdə əməkdaşlığı zamanı daha çevik olmağa imkan verir. Mərkəzləşdirilmiş sistemlərdə hər developer mərkəz nöqtə ilə az ya da çox eyni işləyir. Gitdə hər developer potensial olaraq düyün və mərkəz nöqtədir; hər bir developer həm digər depolara kod dəstəyi verə bilər, həm də başqalarının işləyə biləcəyi və dəstək verə biləcəyi public depo saxlaya bilər. Bu, sizin layihəniz və ya komandanız üçün çox sayda workflow imkanlarını təqdim edir, buna görə də bu rahatlıqdan istifadə edən bir neçə ümumi paradiqma əhatə edəcəyik. Hər dizaynın güclü və mümkün zəif tərəflərini keçəcəyik; bu halda istifadə etmək üçün tək birini seçə bilər və ya bir neçəsinin xüsusiyyətlərini qarışdırıb uyğunlaşdıra bilərsiniz.
Mərkəzləşdirilmiş İş Axınları
Mərkəzləşdirilmiş sistemlərdə sadəcə bir əməkdaşlıq modeli mövcuddur - mərkəzləşdirilmiş iş workflow. Bir mərkəzi nöqtə ya da depo, kodu qəbul edə bilir və o zaman hər kəs öz işini onunla sinxronizasiya edir. Bir sıra developerlər düyünlərdir, yəni o mərkəzin istehlakçılarıdırlar və mərkəzləşdirilmiş yer ilə sinxronizasiya edirlər.
Bu o deməkdir ki, iki developer mərkəzdən klonlanırsa və hər ikisi də dəyişiklik edirsə, dəyişikliklərini geri göndərən ilk tərtibatçı bunu heç bir problem olmadan edə bilər. İkinci developer dəyişiklikləri qeyd etməzdən əvvəl birincinin işində birləşməlidir ki, ilk developerin dəyişikliklərini təkrar yazmasın. Bu anlayış Git-də Subversion (və ya hər hansı CVCS) olduğu kimi doğrudur və bu model Git’də də əla işləyir.
Şirkətinizdə və ya komandanızda mərkəzləşdirilmiş bir workflow ilə onsuz da rahatsınızsa, Git ilə bu iş istifadəsini asanlıqla davam etdirə bilərsiniz. Sadəcə bir depo qurun və komandanızdakı hər kəsə push imkanı verin; bu zaman Git istifadəçilərin bir-birinin üstünə təkrar yazmasına imkan vermir.
Fərz edək ki, John və Jessica eyni anda işə başlayır. John dəyişiklikini bitirib serverə yükləyir. Sonra Jessica dəyişikliklərini yükləməyə çalışır, lakin server onları rədd edir. Ona sürətli olmayan irəli dəyişiklikləri etməyə çalışdığını və qoşulub birləşməyincə edə bilməyəcəyi deyildi. Bu workflow bir çox insanı cəlb edir, çünki o bir çoxunun tanıdığı və rahat olduğu bir paradiqmadır.
Bu həm də kiçik komandalarla məhdudlaşmır. Git-in branch modeli yüzlərlə developerin eyni vaxtda onlarla branch vasitəsilə bir proyekt üzərində uğurla çalışmasını mümkün edir.
İnteqrasiya-Menecer İş Axınları
Git birdən çox uzaq depolarınıza sahib olmağa imkan verdiyi üçün, hər bir developerin öz şəxsi depolarına yazmaq və hər kəsin girişlərini oxumaq üçün bir workflow əldə etməsi mümkündür. Bu ssenariyə tez-tez “official” layihəsini təmsil edən bir kanonik bir depo daxildir. O proyektə dəstək vermək üçün proyektin öz ictimai klonunu yaradırsınız və dəyişikliklərinizi ona istiqamətləndirirsiniz. Sonra dəyişikliklərinizi çəkmək üçün əsas layihənin qoruyucusuna sorğu göndərə bilərsiniz. Ardından saylayıcı, depo saxlayan yerinizi məsafədən əlavə edə bilər, dəyişikliklərinizi yerli olaraq sınayır, onları branch-lara birləşdirə və geri depolarına push edə bilər. Proses aşağıdakı kimi işləyir (İnteqrasiya-menecer İş Axınları-a bax):
-
Layihə qoruyucusu public depolarına push edir.
-
Bir dəstəkçi həmin deponu klonlayır və dəyişikliklər edir.
-
Dəstəkçi öz public kopyasını daxil edir.
-
Dəstəkçi, düzəlişlərin alınmasını xahiş edən bir e-poçt göndərir.
-
Təminatçı dəstəkçinin depolarını uzaqdan əlavə edir və yerli olaraq birləşdirir.
-
Təminatçı birləşmiş dəyişiklikləri əsas depoya daxil edir.
Bu GitHub və ya GitLab kimi hub əsaslı alətlər proyekti forking etmək və dəyişikliklərinizi hamının görə bilməsi üçün fork etmək asan olduğundan çox istifadə olunanlardandır. Bu yanaşmanın əsas üstünlüklərindən biri odur ki, siz işləməyə davam edərkən əsas depo təminatçısı hər an dəyişikliklərinizi daxil edə bilər.
İştirakçılar layihənin dəyişikliklərini daxil etməsini gözləməli deyil - yəni, hər tərəf öz sürətiylə işləyə bilər.
Diktator və Leytenantların İş Axınları
Bu, çoxsaylı depozit bir workflow variantıdır. O, ümumiyyətlə yüzlərlə tərəfdaş ilə birgə nəhəng layihələr tərəfindən istifadə olunur və onun məşhur nümunələrindən biri Linux kernelidir. Müxtəlif inteqrasiya menecerləri depoların müəyyən hissələrinə cavabdehdirlər; onlara leytenantlar deyilir. Bütün leytenantların xeyirxah diktator kimi tanınan bir inteqrasiya meneceri var. Xeyirxah diktator öz direktoriyalarından bütün əməkdaşların çəkməli olduğu bir istinad depolarına göndərir. Proses belə işləyir ( Xeyirxah diktator İş Axınları-a bax):
-
Daimi tərtibatçılar mövzu branch-ları üzərində işləyir və işlərini
master
-in üstünə qoyurlar.master
branch diktatorun göndərdiyi istinad anbarıdır. -
Leytenantlar, developerlərin mövzu şöbələrini öz
master
branch-larına birləşdirirlər. -
Diktator leytenantların
master
branch-larını diktatorun üst branch-na birləşdirir. -
Son olaraq, diktator o
master
bu branch-ı arayış depozitinə göndərir ki, digər tərtibatçılar bunun üzərində yenidən yaza bilsinlər.
Bu cür woekflow çox da işlək deyil, lakin çox böyük layihələrdə və ya yüksək iyerarxik mühitlərdə faydalı ola bilər. Bu layihə rəhbərinə (diktatora) işin çox hissəsini həvalə etməyə və onları birləşdirmədən əvvəl çox nöqtədə böyük kod toplamağa imkan verir.
Mənbə Kodu Branch’larının İdarə Nümunələri
Note
|
Martin Fowler "Mənbə kodu filiallarını idarə etmək üçün nümunələr" kitabçası hazırlamışdır. Bu təlimat bütün ümumi Git workflowlarını əhatə edir və onlardan necə istifadə edəcəyinizi izah edir. Orada həmçinin yüksək və aşağı inteqrasiya tezliklərini müqayisə edən bir bölmə də var. |
İş Axınlarının Qısa Məzmunu
Bəzi Git kimi paylanmış bir sistemlə mümkün olan bir çox istifadə olunan workflowlar vardır, ancaq bir çox dəyişikliyin xüsusi real dünya workflowunuza uyğun olmasının mümkün olduğunu görə bilərsiniz. İndi (ümid edirik ki) hansı iş axını birləşməsinin sizin üçün işləyə biləcəyini müəyyənləşdirə bildiyiniz üçün, müxtəlif axınları təşkil edən əsas rolları necə yerinə yetirəcəyinizə dair daha bir neçə misal göstərəcəyik. Növbəti hissədə bir layihəyə dəstək vermək üçün bir neçə ümumi nümunə haqqında məlumat əldə edəcəksiniz.