Pull Request Nedir?

Bir PR'ın yaşam döngüsü

1. Geliştirici işini ayrı bir branch'te yapar ve branch'i uzak repository'ye gönderir.
2. Bu branch'ten ana branch'e bir pull request açar: ne yapıldığını ve nedenini anlatan bir başlık ve açıklama yazar. İş henüz bitmediyse PR taslak (draft) olarak açılıp erken geri bildirim istenebilir.
3. CI/CD hattı otomatik çalışır: derleme, lint, testler, gerekiyorsa önizleme ortamı.
4. Bir veya daha fazla ekip arkadaşı değişikliği inceler, satırlara yorum bırakır, onay verir ya da değişiklik ister.
5. Yazar geri bildirime göre yeni commit'ler ekler; kontroller yeniden çalışır.
6. Onay ve başarılı kontrollerden sonra PR birleştirilir, branch silinir ve değişiklik yayına giden yola girer.

Birleştirme yöntemi ekibin geçmişi nasıl görmek istediğine bağlıdır. GitHub üç seçenek sunar: tüm commit'leri koruyup bir merge commit'i ekleyen merge, PR'daki commit'leri tek commit'e indiren squash and merge ve commit'leri merge commit'i olmadan ana branch'in üzerine dizen rebase and merge. Ara “düzeltme” commit'leriyle dolu PR'larda squash, geçmişi okunur tutar.

İyi bir PR açıklaması

İnceleyen kişi değişikliğin bağlamını bilmez. Kısa ama eksiksiz bir açıklama, incelemenin hem hızını hem kalitesini artırır:

## Ne değişti?
Sipariş formunda vergi numarası alanı zorunlu hale getirildi (yalnızca kurumsal müşteri).

## Neden?
Muhasebe, kurumsal siparişlerde vergi numarası eksikliği nedeniyle faturaları elle düzeltiyor.

## Nasıl test edilir?
1. Kurumsal hesapla giriş yap, sepete ürün ekle
2. Vergi numarası boşken siparişi göndermeyi dene: hata mesajı görünmeli

## Riskler
Mevcut bireysel müşteri akışı etkilenmemeli; ilgili testler eklendi.

Arayüz değişikliklerinde öncesi/sonrası ekran görüntüleri, veritabanı değişikliklerinde ise migrasyonun geri alınıp alınamayacağı bilgisi açıklamaya eklenmelidir.

Code review'da neye bakılır?

Kod incelemesinin amacı yazarı sınamak değil, hatayı canlıya çıkmadan yakalamak ve bilgiyi ekip içinde yaymaktır. İnceleyenin zamanı en çok şu sorulara harcanmalıdır:

• Doğruluk: Kod, açıklamada söyleneni gerçekten yapıyor mu? Sınır durumlar, boş değerler, hata yolları ele alınmış mı?
• Güvenlik: Kullanıcı girdisi doğrulanıyor mu, yetki kontrolü doğru yerde mi, bir gizli bilgi koda girmiş mi?
• Testler: Davranışı koruyan birim testleri eklenmiş mi, yoksa yalnızca mutlu senaryo mu deneniyor?
• Okunabilirlik ve tasarım: Altı ay sonra bu kodu değiştirecek kişi neyin neden yapıldığını anlayabilecek mi?

Girinti, tırnak tercihi gibi biçim konuları insana bırakılmamalıdır; formatter ve linter bu tartışmaları otomatik olarak bitirir. Yorumlarda da “bu birleştirmeyi engeller” ile “küçük bir öneri, tercihe bağlı” ayrımını açıkça yapmak, PR'ın gereksiz yere günlerce beklemesini önler.

Boyut, incelemenin kalitesini belirler

Yirmi satırlık bir PR dikkatle okunur; iki bin satırlık bir PR ise çoğu zaman göz gezdirilip onaylanır. Büyük değişiklikleri parçalara ayırmanın yolları vardır: önce yeniden düzenleme (refactor) sonra davranış değişikliği, önce veritabanı şeması sonra onu kullanan kod, yarım özellikleri feature flag arkasında birleştirmek. Uzun süre açık kalan büyük PR'lar ayrıca conflict riskini artırır ve “sonra düzeltiriz” denilen her yorum teknik borç olarak birikir.

Korumalı branch ve zorunlu kontroller

Ekip kuralları yalnızca alışkanlığa bırakılmamalıdır. GitHub'ın korumalı branch ayarları ile ana branch için belirli sayıda onay, başarılı durum kontrolleri, CODEOWNERS dosyasında tanımlı kod sahiplerinin onayı ve son push'u yapan kişiden başka birinin onayı zorunlu tutulabilir. Böylece hiçbir değişiklik, en az bir başka gözden ve otomatik testlerden geçmeden canlıya gidemez.