Onaylama / Onay almak: nedir, Git’te onay ve code review

Pull request onayı nedir

Onay, bir pull request hakkında olumlu bir değerlendirmedir; inceleyicinin kodu kontrol ettiği, kritik sorun bulmadığı ve değişiklikleri birleştirmeye hazır gördüğü anlamına gelir. GitHub arayüzünde bu, PR sayfasındaki yeşil «Approve» düğmesidir. Onaydan sonra yazar (veya yazma iznine sahip herhangi bir üye) birleştirme işlemini gerçekleştirebilir.

Onay süreci Branch Protection Rules’un bir parçasıdır. Depo sahipleri zorunlu gereksinimleri yapılandırır: minimum onay sayısı (örneğin 1 veya 2), kimlerin onaylayabileceği (kod sahipleri, ekip üyeleri) ve değişikliklerden sonra PR’nin yeniden onaylanması gerekip gerekmediği (Dismiss stale reviews). Kural yapılandırması olmadan onay isteğe bağlıdır, ancak profesyonel ekiplerde zorunludur.

GitLab, Approval Rules adı verilen benzer bir mekanizma kullanır. GitLab’da farklı gruplardan kaç onay gerektiğini yapılandırabilirsiniz (örneğin backend geliştiricilerden 2 ve DevOps’tan 1). Tüm zorunlu onaylar alındıktan sonra, CI/CD hattı yeşil olduğu sürece PR otomatik olarak birleştirme için serbest bırakılır.

İnceleme türleri: Approve, Request Changes, Comment

GitHub ve GitLab, bir inceleyicinin pull request üzerinde bırakabileceği üç tür inceleme sunar. Her türün farklı bir durumu ve birleştirme süreci için farklı sonuçları vardır. Approve yeşil, Request Changes kırmızı, Comment nötr gridir. Seçim, kod kalitesine ve değişikliklerin kabul için hazır olma durumuna bağlıdır.

Approve — inceleyici onaylar: kod doğru yazılmış, standartları karşılıyor, belirgin hata içermiyor ve birleştirilebilir. Approve, kodun mükemmel olduğu anlamına gelmez — sadece üretim için yeterince iyi olduğu anlamına gelir. Küçük notlar (stil, adlandırma) varsa, PR’yi engellemeden yorum olarak bırakılabilir.

Request Changes — inceleyici birleştirme öncesinde düzeltilmesi gereken sorunlar bulur: mantık hataları, güvenlik açıkları, mimari ihlaller, test eksiklikleri. Request Changes’ten sonra PR engellenir ve aynı inceleyicinin yeniden onayı gerekir (yeni commit’lerde Dismiss stale reviews seçeneği etkinse).

• Approve — kod birleştirmeye hazır, CI geçtikten sonra birleştirilebilir.
• Request Changes — zorunlu düzeltmeler, yeniden incelemeye kadar PR engellendi.
• Comment — PR’yi engellemeden genel not veya öneri.

Depoda onay kurallarını yapılandırma

Branch Protection Rules, GitHub’ın birleştirme kalitesini kontrol etme mekanizmasıdır. Korunan her dal için (main, develop, release/*) Settings → Branches altında yapılandırılır. Ana parametreler: zorunlu onay sayısı, kod sahipleri (CODEOWNERS), zorunlu CI/CD kontrolü ve PR olmadan push yasağı.

Dismiss stale pull request approvals parametresi, PR’ye yeni bir commit eklendiğinde onayları otomatik olarak kaldırır. Bu, inceleyicilerin birleştirilecek kodun tam sürümünü onaylamasını sağlar. Bu ayar olmadan, yazar onaydan sonra yeni kod ekleyebilir ve bu kod yeniden kontrol edilmeden main’e ulaşabilir.

CODEOWNERS — deponun kökündeki, farklı dizinler için sorumluları atayan bir dosyadır. Bir PR, bir kod sahibine ait dosyaları etkiliyorsa, onun onayı zorunlu hale gelir. CODEOWNERS, sorumluluk alanlarını dağıtmayı sağlar: iOS geliştiricileri Swift dosyalarından, DevOps Docker yapılandırmalarından, testçiler test senaryolarından sorumludur.

# Depo kökünde örnek CODEOWNERS dosyası

# iOS geliştiricileri Swift koduna sahiptir
*.swift @team/ios-developers

# DevOps CI/CD yapılandırmasına sahiptir
.github/workflows/* @devops-team

# QA mühendisleri testleri inceler
**/tests/* @qa-engineers

# Diğer her şey için varsayılan sahipler
* @tech-leads

Onay öncesi code review: ne kontrol etmeli

Onay öncesi code review, diff’e hızlı bir bakış değil, sistematik bir kod kontrolüdür. Kaliteli bir code review, mimari, mantık, stil, testler ve güvenlik kontrolünü içerir. Bu kontrol olmadan onay, bir kalite kontrol aracı olmaktan çıkıp bir formaliteye dönüşür.

İlk olarak ne kontrol edilir: değişikliklerin mantığı — kod görevi çözüyor mu, yan etkiler var mı, sınır durumların işlenmesi doğru mu. Testler — yeni testler tüm senaryoları kapsıyor mu, mevcut testler değişikliklerden sonra geçiyor mu. Güvenlik — SQL enjeksiyonu, XSS, hassas veri sızıntısı var mı.

İncelemenin konusu olmaması gerekenler: biçimlendirme stili (bunun için linter’lar ve biçimlendiriciler vardır), önceden alınmış mimari kararlar (kod yazılmadan önce tartışılır). Bir inceleme 400 satırı aşıyor veya bir saatten fazla sürüyorsa, bu görevin çok büyük olduğunun ve parçalanması gerektiğinin işaretidir. En iyi inceleme uygulamaları — PR oluşturulduktan sonra 24 saat içinde 200–400 satırlık bölümler.

• Mantık — çözümün doğruluğu, hata işleme, sınır durumlar.
• Testler — yeni senaryoların kapsanması, mevcut testlerin geçmesi, flaky test olmaması.
• Güvenlik — enjeksiyon yok, çıktı kaçışı yok, veri erişim kontrolü.
• Performans — algoritma verimliliği, aşırı sorgular, bellek sızıntıları.
• Belgeler — belgeler güncellenmiş mi, karmaşık bölümlerdeki yorumlar açık mı.

Ekipte onay ile çalışma akışı

5–10 geliştiriciden oluşan bir ekipte tipik bir onay iş akışı şöyledir: bir geliştirici PR oluşturur, inceleyiciler atar (genellikle ekipten 1–2 kişi veya kod sahipleri), CI/CD otomatik kontrolleri çalıştırır. Tüm zorunlu onaylar ve yeşil CI alındıktan sonra yazar birleştirme yapar. PR oluşturmadan birleştirmeye kadar geçen süre, karmaşıklığa bağlı olarak ortalama 2 saat ile 2 gün arasındadır.

GitHub Actions, onaydan sonra birleştirmeyi otomatikleştirmeye izin verir. Dal kuralları yapılandırılmışsa, GitHub tüm koşullar yerine getirilene kadar birleştirmeyi otomatik olarak engeller. Bazı ekipler bors-ng veya Mergify kullanır — tüm onaylar alındıktan ve CI geçtikten sonra PR’leri otomatik olarak birleştiren botlar. Bu, süreci hızlandırır ve birleştirmede insan faktörünü ortadan kaldırır.

Modern bir yaklaşım, kısa ömürlü dallarla trunk-based development’dır. Bu iş akışında, onay birkaç saat içinde alınmalıdır, aksi takdirde görev güncel olmadığı için main ile yeniden senkronizasyon gerekir. Yüksek inceleme kültürüne sahip ekipler, onay süresini 4 çalışma saatinden fazla olmayacak şekilde hedefler.

Onay hataları ve bunlardan kaçınma yolları

En yaygın hata, gerçek kod kontrolü olmadan yapılan resmi onaydır. PR büyük olduğunda veya son tarih yaklaştığında, inceleyici değişiklikleri incelemeden Approve’a tıklayabilir. Bu, tüm code review sürecini değersizleştirir. Çözüm: PR boyutuna bir sınır koyun (400 satırdan fazla olmamalı) ve otomatik kontrol için kod analiz araçları (SonarQube, CodeClimate) kullanın.

İkinci hata, aşırı katı onaydır. Mükemmel kod beklemek geliştirmeyi engeller. İnceleyiciler bazen kaliteyi etkilemeyen stilistik notların düzeltilmesini ister. Çözüm: zorunlu notları (engelleyici) ve isteğe bağlı önerileri (yorumlar) net bir şekilde ayırın. GitHub, bir yorumun engelleyici olup olmadığını açıkça belirtmenize olanak tanır.

Üçüncü hata, CI/CD’yi kontrol etmeden onay vermektir. Kod doğru görünse bile derlenmeyebilir veya testlerde başarısız olabilir. Yapılandırılmış Branch Protection, kırmızı CI’da birleştirmeyi otomatik olarak engeller, ancak bazı ekipler hız için bu korumayı devre dışı bırakır. Çözüm: onaylamadan önce her zaman CI durumunu kontrol edin ve kırmızı hattı olan bir PR’yi asla onaylamayın.

• Resmi onay — gerçek kod kontrolünün olmaması. Çözüm: PR başına 400 satır sınırı.
• Aşırı katılık — stilistik notlar nedeniyle engelleme. Çözüm: blocking ve optional olarak ayırın.
• CI’yı görmezden gelme — kırmızı hatta onay. Çözüm: her zaman test durumunu kontrol edin.
• Yazar ataması — PR yazarı tarafından onay. Çözüm: yazara karşı Branch Protection yapılandırın.