Pull Request-lərin sehri

1. Birləşdirmədən təklifə: Pull Request-lər nə üçün lazımdır?

Ötən mühazirədə budaqları lokal kompüterinizdə birləşdirməyi (merge) öyrəndik. Tək işləyərkən bu əla işləyir. Bəs layihə üzərində bütün bir komanda işləyirsə? Hər kəs öz dəyişikliklərini birbaşa əsas main budağına birləşdirsə, tezliklə xaos başlayacaq: kimsə təsadüfən xətalı kod əlavə edə, yığımı (build) poza və ya həmkarının işinin vacib hissəsini silə bilər.

Bunun qarşısını almaq üçün komanda inkişafında başqa bir yanaşma qəbul edilib. Dəyişiklikləri dərhal birləşdirmək əvəzinə, siz birləşdirmə üçün təklif yaradırsınız. Bu təklif Pull Request (qısaca PR) adlanır, bəzən platformalarda Merge Request də deyilə bilər.

Pull Request — bu rəsmi bir xahişdir: “Zəhmət olmasa, mənim budağımdan (pull) dəyişikliklərimi götürün və onları əsas budağa (merge) əlavə edin”. Amma bu, sadəcə bir xahiş deyil, həm də kodun main budağına düşməsindən əvvəl müzakirə, yoxlama və təkmilləşdirmə üçün tam bir meydançadır.

2. Pull Request ilə standart iş axını

Gəlin addım-addım yeni funksionallıq yaradarkən tipik iş axınını nəzərdən keçirək.

Yeni tapşırıq üçün budaq yaratmazdan əvvəl, bütün tamamlanmış commit-lərinizi göndərdiyinizə (push) və əsas main budağını yenilədiyinizə (Update Project) əmin olun.

Əks halda, main budağındakı “unudulmuş” lokal commit-ləriniz təsadüfən yeni Pull Request-ə düşəcək və həmkarlarınız üçün çaşqınlıq yaradacaq.

Addım 1. Yeni tapşırıq üçün budaq yaradın.

Əvvəlki kimi, hər yeni iş ayrıca budaq yaratmaqla başlayır. Tutaq ki, layihəmizə kontribyutorlar üçün qaydalar olan bir fayl əlavə etmək istəyirik. feature/add-contribution-guide budağını yaradaq.

Addım 2. Dəyişikliklər edin və budağınızı GitHub-a göndərin.

Yeni budaqda CONTRIBUTING.md faylını yaradın (yaratdıqdan sonra Add düyməsini basın) və orada digər tərtibatçılar üçün mesajınızı yazın. Bundan sonra anlaşıqlı bir mesajla Commit and Push edin, məsələn: docs: Add contribution guide.

Bu əsas addımdır! Pull Request artıq uzaq serverdə mövcud olan budaq əsasında yaradılır. Buna görə də PR yaratmazdan əvvəl yeni budağınızı GitHub-a göndərməlisiniz (push).

3. IntelliJ IDEA-dan Pull Request yaradılması

Artıq budağınız GitHub-dadırsa, Pull Request yarada bilərsiniz.

Addım 1. Pull Requests nişanını açın.

IDE-nin sol tərəfində Pull Requests nişanı yerləşir. Onu açın və yeni PR yaratmaq üçün + ikonuna klikləyin.

Addım 2. PR üçün məlumatları doldurun.

IDE Pull Request yaratmaq üçün rahat interfeysi avtomatik açacaq. Sizin vəzifəniz — onu düzgün və dolğun doldurmaqdır. Gəlin əsas sahələri nəzərdən keçirək:

1. Başlıq: IDE tez-tez bura budağın adını yerləşdirir, amma bu yaxşı təcrübə deyil. Başlıq qısa, anlaşıqlı olmalı və dəyişikliklərin mahiyyətini əks etdirməlidir — yaxşı commit mesajı kimi.
2. Təsvir: burada nə və nəyə görə etdiyinizi izah edirsiniz.
3. Rəylər (reviewers): burada kodunuzu yoxlamalı olan bir və ya bir neçə həmkarınızı seçirsiniz. Tədris layihəsində bu addımı ötürəcəyik, lakin real işdə bu mütləqdir.
4. Məsul şəxs (assignees): adətən burada özünüzü göstərirsiniz. Bu o deməkdir ki, siz — bu tapşırığın müəllifi və rəy sonrası düzəlişlərə görə əsas məsul şəxsiniz.

Bütün sahələri doldurduqdan sonra inamla Create Pull Request düyməsini basın.

4. Kod rəyi: yoxlama və müzakirə

PR yaradıldıqdan sonra ən vacib mərhələ — code review başlayır. Həmkarlarınız PR-ı açıb bütün dəyişikliklərə baxa və şərhlər yaza bilərlər.

Bütün müzakirələri birbaşa IDE-də, Pull Requests nişanında görə bilərsiniz. Kimsə şərh yazarsa, bildiriş alacaqsınız.

Əgər sizdən düzəliş etməyi xahiş etdilərsə nə etməli?

Çox sadədir! Yeni PR yaratmağa ehtiyac yoxdur. Lazımi dəyişiklikləri elə həmin budaqda edin, yeni commit atın və onu göndərin (push). GitHub-dakı Pull Request avtomatik yenilənəcək və yeni commit-lərinizi əlavə edəcək.

5. İşin tamamlanması: birləşdirmə və budağın silinməsi

Bütün qeydlər düzəldildikdən və komanda dəyişikliklərinizi təsdiqlədikdən sonra Pull Request-i birləşdirmək olar. Adətən bunu aparıcı tərtibatçı edir və ya icazəniz varsa siz özünüz də edə bilərsiniz.

Addım 1. Merge

Birləşdirmə çox vaxt GitHub saytında baş verir. Orada PR-ınızın altında böyük yaşıl Merge pull request düyməsi görünəcək. Ona basdıqdan sonra kodunuz əsas main budağının bir hissəsi olacaq.

Addım 2. Budağın silinməsi.

Birləşdirmədən sonra sizin `feature` budağınız artıq lazım deyil və repozitoriyanı çirkləndirməmək üçün onu silməyə dəyər. GitHub bunu təklif edəcək — Delete branch düyməsini göstərəcək.

Nizam-intizamı qorumaq üçün IDE-nizdə lokal budaq nüsxəsini də silməyi unutmayın. Bunu eyni budaq idarəetmə menyusundan etmək olar.

6. Commit üçün üç qayda

Yaxşı commit təkcə düzgün mesaj deyil, həm də düzgün məzmundur. Dəyişiklik tarixçənizin səliqəli, faydalı və peşəkar olması üçün üç sadə qaydaya əməl edin.

Qayda 1: standartlara uyğun, aydın commit mesajları yazın

Commit-ləriniz — komandaya və gələcəkdə özünüzə göndərdiyiniz mesajlardır. “fix” və ya “update” kimi mesajlarla dolu tarixçə tamamilə yararsızdır. Ən populyar standart Conventional Commits adlanır. O, aşağıdakı quruluşu təklif edir:

<tip>: <qısa təsvir>

Tip — dəyişikliklərinizin kateqoriyasını təsvir edən qısa sözdür:

• feat: (feature) — yeni funksionallıq üçün.
• fix: — xəta düzəlişi üçün.
• docs: — sənədləşmədə dəyişikliklər üçün.
• style: — kodun məntiqinə təsir etməyən formatlama düzəlişləri üçün.
• refactor: — nə yeni funksionallıq əlavə edən, nə də xətaları düzəldən kod dəyişiklikləri üçün.
• test: — testlərin əlavə edilməsi və ya düzəldilməsi üçün.
• chore: — koda birbaşa aid olmayan rutin işlər üçün (asılılıqların yenilənməsi, yığımın qurulması və s.).

Nümunələr:

• Pis: fixed bug
• Yaxşı: fix: Correct user login validation

• Pis: readme
• Yaxşı: docs: Update installation instructions

Qayda 2: bir commit — bir məntiqi dəyişiklik (Atomiklik)

Bir commita həm xəta düzəlişini, həm yeni funksiya əlavə edilməsini, həm də köhnə kodun refaktorunu sığdırmağa çalışmayın. Belə commit-i yoxlamaq çox çətindir və nəsə alınmasa, ağrısız şəkildə geri almaq demək olar ki, mümkün deyil.

Hər bir commit yalnız bir konkret məsələnin həllinə xidmət etməlidir.

• Pis: “Update user page” mesajlı bir commit — avatar sahəsi əlavə edir, adın yoxlanmasını düzəldir və düymələrin rəngini dəyişir.
• Yaxşı: üç ayrı commit:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Kiçik və fokuslanmış commit-lər anlamaq və idarə etmək baxımından daha rahatdır.

Qayda 3: Commit layihəni sındırmamalıdır

Əsas budaqdakı hər commit layihəni işlək vəziyyətdə saxlamalıdır. Onu yaratmazdan əvvəl ən azı kodun kompilyasiya olunduğuna əmin olmalısınız. Bəs sistemin başqa hissəsində nəyisə təsadüfən sındırmadığınızdan necə əmin olasınız? Yalnız əl ilə yoxlamaya güvənmək risklidir.

Burada avtomatlaşdırma köməyə gəlir. Bu kursda avtomatik prosesləri qurmayaçağıq, amma real layihələrdə bunun necə işlədiyini bilməlisiniz. Müasir komandalar GitHub Actions kimi davamlı inteqrasiya (Continuous Integration, CI) sistemlərindən istifadə edirlər.

Bu necə işləyir?

Siz kod və ona testlər yazırsınız. Sonra xüsusi ssenari (workflow) birbaşa GitHub-da qurulur. İndi siz Pull Request-ə push göndərən kimi sehr baş verir:

1. GitHub Actions bu hadisəni görür və ssenarinizi işə salır.
2. O, layihəni avtomatik “yığır” və bütün testləri işə salır.
3. Əgər bütün testlər uğurla keçərsə, GitHub-da commit-inizin yanında yaşıl işarə görünür. Bu, bütün komanda üçün dəyişikliklərinizin təhlükəsiz olduğuna siqnaldır.
4. Ən azı bir test uğursuz olarsa, qırmızı çarpaz işarə görəcəksiniz. Belə PR-i əsas budağa birləşdirmək qəti qadağandır.

            graph LR
            subgraph GitHub
            A[Tərtibatçı] -- "push" --> B(Repozitoriya)
            B -- "Hadisə: push" --> C{GitHub Actions}
            end

            subgraph Workflow
            C -- "Başlatma" --> D[Testlərin_işə_salınması]
            D --> E[Uğurlu]
            D --> F[Uğursuz]
            end

            subgraph Notifications
            F --> G((Email))
            G --> H[Tərtibatçı]
            G --> I[Komanda]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

Bildirişləri qurmaq olar. Əgər testlər uğursuz olarsa, GitHub Actions sizə və ya bütün komandaya məktub göndərə bilər. Bu yanaşma elə bir mədəniyyət yaradır ki, testlər sadəcə formalıq deyil, inkişafın ayrılmaz hissəsidir və hər kəs öz kodunun keyfiyyətinə görə məsuliyyət daşıyır.