GitHub Pull Request İnceleme Süreci

Pull request, kodun "bitti" ile "yayında" arasındaki son kapısıdır. Bu kapıda ne kadar dikkatli davranırsan, üretimde o kadar az sürprizle karşılaşırsın. Ama çoğu ekipte inceleme ya çok yüzeysel geçer (iki dakikada "LGTM") ya da haftalarca sürüncemede kalır. İkisi de aynı sebepten olur: sürecin adımları yazılı değildir.

Aşağıdaki akışı tek başına, kişisel bir depoda bile uygulayabilirsin. Kendi PR'ını kendin incelemek, alışkanlık kazanmanın en hızlı yolu. Git komutlarında rahat değilsen, dallanma ve rebase konularını Git Workflow Pratik Rehberi'ndeki adımlarla tazelemek işini kolaylaştırır.

İncelenebilir Bir Pull Request Hazırlamak

İyi bir pull request inceleme süreci, incelemeciden değil PR'ı açan kişiden başlar. Okunamayan bir diff, en iyi incelemeciyi de yorar.

Değişikliği küçük ve tek amaçlı tut

• Bir PR = bir amaç. "Login hatası düzeltildi + logger refactor + npm paketleri güncellendi" üç ayrı PR'dır.
• Hedef aralık: 200-400 satırlık diff. Bunun üstünde inceleme kalitesi hızla düşer.
• Formatlama ve isim değişikliklerini ayrı bir commit'e, mümkünse ayrı bir PR'a al. Yoksa gerçek mantık değişikliği 300 satır beyaz boşluk arasında kaybolur.
• Büyük bir işi bölemiyorsan, PR açıklamasında "önce şu dosyaya bak, gerisi otomatik üretim" diye yol göster.

Açıklamayı kullanım kılavuzu gibi yaz

İncelemeci senin kafandakini bilmiyor. Açıklamada şu dört başlık olsun:

1. Ne: Tek cümleyle değişiklik.
2. Neden: Hangi issue, hangi hata, hangi ölçüm.
3. Nasıl test ettim: Çalıştırılan komutlar, gidilen ekranlar, istek örnekleri. API değişikliği varsa örnek istek/yanıt yapıştır; REST API Test Etme Araçları sayfasındaki koleksiyon mantığı burada işe yarar.
4. Riskler: Geri alınabilir mi, veritabanı migration'ı var mı, feature flag arkasında mı.

İlk incelemeyi kendin yap

• PR'ı aç, "Files changed" sekmesine geç ve diff'i yabancı gözüyle oku. Yarısını burada yakalarsın.
• Kalan console.log, yorum satırına alınmış kod, TODO'lar, deneme dosyaları temizlenir.
• Diff'te API anahtarı, token, bağlantı dizesi var mı diye ara. Sızan bir sır, merge'den sonra geçmişte kalır; Güvenli Şifre Saklama Yöntemleri'ndeki yaklaşımı baştan uygula.
• CI yeşil olmadan incelemeci çağırma. Lint ve test hatalarını incelemeciye buldurmak, insan zamanını makine işine harcamaktır.
• Kendi PR'ına satır içi yorum bırakabilirsin: "Burada döngüyü bilerek bıraktım, çünkü…" Bu, gelecek soruların yarısını kapatır.

İnceleme Sürecini Yürütmek: Diff'ten Merge'e

Diff'i doğru sırada oku

Rastgele dosya açmak yerine sabit bir sıra izle:

1. Açıklama ve issue.
2. Testler. Yeni davranış testte görünüyorsa, kodun ne yaptığını zaten anlamışsın demektir.
3. Veri modeli, migration, şema. Geri dönüşü en pahalı kısım burası. Sorgu ekleniyorsa indeks var mı diye düşün; SQL Veri Tabanı Optimizasyon İpuçları'ndaki N+1 ve indeks kontrolleri iyi bir kontrol listesi.
4. İş mantığı.
5. Arayüz, stil, kozmetik dosyalar.

Karmaşık PR'larda dalı yerel makinene çek ve çalıştır. gh pr checkout ya da düz Git ile indirip editörde gezmek, tarayıcıdaki diff'ten çok daha fazlasını gösterir. Editörünü hızlı gezinmeye ayarlamak için VS Code'u Hızlandırma Tricksleri'ndeki kısayollar burada doğrudan işe yarar.

Yorumları etiketle ve niyetini belirt

Belirsiz yorum, gereksiz tartışma üretir. Yorumun başına ne beklediğini yaz:

• Kişiyi değil kodu konuş: "bu fonksiyon iki iş yapıyor", "sen yanlış yazmışsın" değil.
• Somut alternatif ver. GitHub'ın öneri bloğu tek tıkla uygulanır, karşılıklı yazışmayı bitirir.
• Aynı hata beş yerde tekrarlanıyorsa beş yorum yazma; bir yorumda "bu kalıp dosya boyunca geçerli" de.
• Biçim tartışmalarını insandan araca devret. Formatter ve lint kuralları, tekrarlayan denetimleri Bash Script Yazma R
  © 2026 Yazılım Atölyesi