Apruv etmək / Təsdiqləmək: bu nədir, approval və code review Git-də

Pull request-in apruvu nədir

Apruv (approval) — bu pull request-ə müsbət rəydir, yəni rəyçi kodu yoxladı, kritik problemlər tapmadı və dəyişiklikləri birləşdirməyə hazır hesab edir. GitHub interfeysində bu, PR səhifəsindəki yaşıl «Approve» düyməsidir. Apruvdan sonra müəllif (və ya yazmaq hüququ olan istənilən iştirakçı) merge edə bilər.

Apruv prosesi Branch Protection Rules-un bir hissəsidir. Repozitoriya sahibləri məcburi tələbləri konfiqurasiya edir: minimum apruv sayı (məsələn, 1 və ya 2), kimin apruv edə biləcəyi (kod sahibləri, komanda üzvləri) və PR-in dəyişikliklərdən sonra təkrar apruv edilməli olub-olmaması (Dismiss stale reviews). Qaydalar konfiqurasiya edilmədikdə apruv isteğə bağlı addımdır, lakin peşəkar komandalarda məcburidir.

GitLab Approval Rules adlı oxşar mexanizmdən istifadə edir. GitLab-da müxtəlf qruplardan (məsələn, backend tərtibatçılarından 2 və DevOps-dan 1) nə qədər apruv tələb olunduğunu konfiqurasiya etmək olar. Bütün məcburi apruvlar alındıqdan sonra PR yaşıl CI/CD pipeline şərti ilə avtomatik olaraq merge üçün blokdan çıxarılır.

Rəy növləri: Approve, Request Changes, Comment

GitHub və GitLab-da rəyçinin pull request-ə buraxa biləcəyi üç növ rəy var. Hər növün birləşdirmə prosesi üçün fərqli statusu və nəticələri var. Approve — yaşıl, Request Changes — qırmızı, Comment — neytral boz. Növün seçimi kodun keyfiyyətindən və dəyişikliklərin qəbul edilməyə hazırlığından asılıdır.

Approve — rəyçi təsdiqləyir: kod düzgün yazılıb, standartlara uyğundur, açıq səhvlər yoxdur və birləşdirilə bilər. Approve kodun mükəmməl olduğunu deyil — yalnız istehsal üçün kifayət qədər yaxşı olduğunu bildirir. Kiçik qeydlər varsa (stil, adlandırma), onları PR-i bloklamadan şərh kimi buraxmaq olar.

Request Changes — rəyçi merge-dən əvvəl düzəldilməli olan problemlər tapır: məntiqi səhvlər, zəifliklər, memarlıq pozuntuları, testlərin olmaması. Request Changes-dən sonra PR bloklanır və blokdan çıxmaq üçün eyni rəyçidən təkrari apruv tələb olunur (yeni commit-lərdə Dismiss stale reviews opsiyası aktivdirsə).

• Approve — kod birləşdirməyə hazırdır, CI keçdikdən sonra merge etmək olar.
• Request Changes — məcburi düzəlişlər, PR təkrari rəyə qədər bloklanıb.
• Comment — PR-i bloklamadan ümumi qeyd və ya təklif.

Repozitoriyada apruv qaydalarının konfiqurasiyası

Branch Protection Rules — bu GitHub-da birləşdirmə keyfiyyətinə nəzarət mexanizmidir. Hər qorunan filial (main, develop, release/*) üçün Settings → Branches bölməsində konfiqurasiya edilir. Əsas parametrlər: məcburi apruvların sayı, kod sahibləri (CODEOWNERS), məcburi CI/CD yoxlaması və PR olmadan push qadağanı.

Dismiss stale pull request approvals parametri — PR-ə yeni commit əlavə edildikdə apruvları avtomatik ləğv edir. Bu, rəyçilərin məhz birləşdiriləcək kod versiyasını apruv etməsini təmin edir. Bu parametr olmadan müəllif apruvdan sonra yeni kod əlavə edə bilər və o, təkrari yoxlama olmadan main-ə düşər.

CODEOWNERS — repozitoriyanın kök qovluğunda müxtəlif qovluqlar üçün məsul şəxsləri təyin edən fayldır. PR kod sahibinə aid fayllara toxunarsa, onun apruvu məcburi olur. CODEOWNERS məsuliyyət zonalarını bölməyə imkan verir: iOS tərtibatçısı Swift fayllarına, DevOps — Docker konfiqlərinə, testçilər — test ssenarilɐ15frinə cavabdehdir.

# Repo kökündə nümunə CODEOWNERS faylı

# iOS tərtibatçıları Swift koduna sahibdir
*.swift @team/ios-developers

# DevOps CI/CD konfiqurasiyasına sahibdir
.github/workflows/* @devops-team

# QA mühəndisləri testləri yoxlayır
**/tests/* @qa-engineers

# Qalan hər şey üçün defolt sahiblər
* @tech-leads

Apruvdan əvvəl code review: nəyi yoxlamaq

Code review apruvdan əvvəl — bu, diff-ə səthi baxış deyil, kodun sistematik yoxlanmasıdır. Keyfiyyətli code review memarlığın, məntiqin, stilinc, testlərin və təhlükəsizliyin yoxlanmasını əhatə edir. Bu yoxlama olmadan apruv formaliteyə çevrilir və keyfiyyətə nəzarət alətinə çevrilmir.

Əvvəlcə nə yoxlanır: dəyişikliklərin məntiqi — kod qarşıya qoyulan tapşırığı həll edirmi, yan təsirlər varmı, sərhəd hallarının işlənməsi düzgündürmü. Testlər — yeni testlər bütün ssenariləri əhatə edirmi, mövcud testlər dəyişikliklərdən sonra keçirmi. Təhlükəsizlik — SQL-inyeksiyaları, XSS, həssas məlumatların sızması varmı.

Nə rəyin predmeti olmamalıdır: formatlaşdırma stili (bunun üçün linterlər və formatterlər var), əvvəlcədən qəbul edilmiş memarlıq qərarları (onlar kod yazılmamışdan əvvəl müzakirə edilir). Rəydə 400 sətirdən çox varsa və ya bir saatdan çox çəkirsə — bu, tapşırığın çox böyük olduğunu və parçalanma tələb etdiyini göstərir. Rəy üçün ən yaxşı təcrübə — PR yaradıldıqdan sonra 24 saat ərzində 200–400 sətirlik hissələr.

• Məntiq — tapşırığın həllinin düzgünlüyü, səhv idarəetməsi, sərhəd halları.
• Testlər — yeni ssenarilərin əhatəsi, mövcud olanların keçməsi, flaky-testlərin olmaması.
• Təhlükəsizlik — inyeksiyaların olmaması, çıxışın ekranlaşdırılması, məlumatlara giriş.
• Məhsuldarlıq — alqoritmlərin səmərəliliyi, artıq sorğular, yaddaş sızmaları.
• Sənədləşdirmə — sənədləşdirmə yenilənibmi, mürəkkəb hissələrdə şərhlər başa düşülürmü.

Komandada apruv ilə iş axını

5–10 tərtibatçıdan ibarət komandada apruv ilə tipik iş axını belə görünür: tərtibatçı PR yaradır, rəyçilər təyin edir (adətən komandadan 1–2 nəfər və ya kod sahibləri), CI/CD avtomatik yoxlamaları işə salır. Bütün məcburi apruvlar və yaşıl CI alındıqdan sonra müəllif merge edir. PR yaradılmasından merge-ə qədər olan müddət mürəkkəblikdən asılı olaraq orta hesabla 2 saatdan 2 günə qədərdir.

GitHub Actions apruvdan sonra merge-i avtomatlaşdırmağa imkan verir. Filial qaydaları konfiqurasiya edilərsə, GitHub bütün şərtlər yerinə yetirilənə qədər merge-i özü bloklayır. Bəzi komandalar bors-ng və ya Mergify — bütün apruvları alıb CI keçdikdən sonra PR-i avtomatik birləşdirən botlardan istifadə edir. Bu, prosesi sürətləndirir və merge zamanı insan faktorunu aradan qaldırır.

Müasir yanaşma — qısaömürlü filiallarla trunk-based development. Bu iş axınında apruv bir neçə saat ərzində alınmalıdır, əks halda tapşırıq köhnəlmiş sayılır və main ilə təkrari sinxronizasiya tələb edir. Yüksək rəy mədəniyyətinə malik komandalar 4 iş saatından çox olmayan apruv müddətinə can atırlar.

Apruvda səhvlər və onlardan necə qaçınmaq

Ən tez-tez rast gəlinən səhv — kodun həqiqi yoxlanması olmadan formal apruv. PR böyük və ya deadline yaxın olduqda, rəyçi dəyişikliklərə varmadan Approve düyməsini basa bilər. Bu, bütün code review prosesini dəyərsizləşdirir. Həll yolu: PR ölçüsünə limit qoymaq (400 sətirdən çox olmamaq) və avtomatik yoxlama üçün kod analizi alətlərindən (SonarQube, CodeClimate) istifadə etmək.

Ikinci səhv — həddindən artıq sərt apruv. Mükəmməl kod gözləməsi inkişafı bloklayır. Rəyçilər bəzən keyfiyyətə təsir etməyən stilistik qeydləri düzəltməyi tələb edirlər. Həll yolu: məcburi qeydləri (bloklayan) və isteğə bağlı təklifləri (şərhlər) aydın şəkildə ayırmaq. GitHub şərhin bloklayıb-bloklamadığını aydın göstərməyə imkan verir.

Üçüncü səhv — CI/CD yoxlanmadan apruv. Kod düzgün görünsə belə, o, tərtib olunmaya və ya testlərdə uğursuz ola bilər. Konfiqurasiya edilmiş Branch Protection qırmızı CI zamanı merge-i avtomatik bloklayır, lakin bəzi komandalar sürətləndirmək üçün bu müdafiəni söndürür. Həll yolu: apruvdan əvvəl CI statusunu həmişə yoxlamaq və qırmızı pipeline ilə PR-i heç vaxt təsdiqləməmək.

• Formal apruv — kodun real yoxlanmasının olmaması. Həll yolu: PR-ə 400 sətir limiti.
• Həddindən artıq sərtlik — stilistik qeydlərə görə bloklama. Həll yolu: blocking və optional-a bölmə.
• CI-ın görməməsi — qırmızı pipeline ilə apruv. Həll yolu: həmişə yoxlama statusunu yoxlamaq.
• Müəllifin təyini — PR müəllifindən apruv. Həll yolu: müəllifə qarşı Branch Protection konfiqurasiyası.