Pull Request: nedir, oluşturma süreci ve kod incelemesi

Pull Request Nedir?

Pull Request (PR), dağıtık bir versiyon kontrol sistemi içinde bir daldan diğerine değişiklikleri dahil etmek için yapılan resmi bir taleptir. PR, GitHub, GitLab ve Bitbucket platformlarında işbirlikçi geliştirmenin merkezi bir öğesidir ve kod tartışması, otomatik testler ve değişiklik onay sürecini birleştirir.

“Pull Request” adı, işlemin özünü yansıtır: bir geliştirici, depo sahibinden değişikliklerini “çekmesini” (pull) ister (request). Terim, 2008 yılında GitHub tarafından tanıtıldı — bundan önce, benzer bir mekanizma yamalar ve merge request'ler (GitLab'ın terimi) şeklinde mevcuttu. Bugün PR, Git ile ekip geliştirmenin fiili standardıdır.

GitHub Octoverse, 2025'e göre, açık kaynak projelerin %89'u değişiklik yapmak için PR oluşturulmasını gerektirir. Kurumsal geliştirmede bu rakam %95'e ulaşmaktadır. PR yalnızca teknik bir araç değil, geliştirme kültürünün bir parçası haline gelmiştir: PR'lar aracılığıyla bilgi aktarımı, hata tespiti ve mimari kararların uyumlaştırılması gerçekleşir.

Pull Request Bileşenleri

Tipik bir PR, başlık, açıklama, değiştirilen dosyaların listesi (diff), inceleyen yorumları ve CI kontrol durumlarından oluşur. Her PR, belirli bir kaynak dal ve hedef dal ile bağlantılıdır ve birleştirmeden sonra otomatik olarak silinebilir.

Pull Request Nasıl Oluşturulur

PR oluşturma, uzak depoya bir özellik dalı yayınlamakla başlar. Push'tan sonra, geliştirici platform arayüzü veya CLI (gh, glab) aracılığıyla bir PR açar. Süreci GitHub örneği ile inceleyelim.

Dalı Push'lama ve PR Açma

İlk adım, özellik dalını uzak depoya push'lamak ve web arayüzü veya komut satırı aracılığıyla bir Pull Request oluşturmaktır.

# Özellik dalı oluştur ve push'la
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# GitHub CLI aracılığıyla PR oluştur
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Bir PR oluşturulduktan sonra, GitHub otomatik olarak CI pipeline'larını (GitHub Actions) çalıştırır, hedef dal ile çakışmaları kontrol eder ve inceleyenleri davet eder. PR açıklama şablonu, .github/PULL_REQUEST_TEMPLATE.md aracılığıyla yapılandırılabilir, böylece tüm PR'lar gerekli bölümleri içerir: hedef, değişiklikler, testler, ilgili görevler.

Açıklama ve Etiketleme

Kaliteli bir PR açıklaması şunları içerir: göreve bağlantı (issue/ticket), değişikliklerin kısa bir açıklaması, test talimatları ve ilgili değişikliklerin listesi. Etiketler (bug, feature, refactoring) PR'ı kategorize etmeye yardımcı olurken, assignee'ler ve reviewer'lar CODEOWNERS aracılığıyla otomatik olarak atanır.

# CODEOWNERS aracılığıyla inceleyenleri ata (depo kökündeki dosya)
# Örnek .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# gh cli aracılığıyla inceleyen atayarak PR oluştur
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS, değiştirilen dosyalara göre inceleyenleri otomatik olarak atamak için standart bir GitHub/GitLab mekanizmasıdır. Örneğin, src/auth/ dizinindeki herhangi bir değişiklik, otomatik olarak team-auth ve senior-dev'i inceleyen olarak atar. Bu, süreci hızlandırır ve doğru kişilerin PR'ı görmesini sağlar.

İncelemeye Göre PR Güncelleme

İnceleyenin yorumlarını aldıktan sonra, geliştirici aynı özellik dalında düzeltmeler yapar ve yeni commit'ler push'lar — PR otomatik olarak güncellenir. PR zaten açıksa, yayınlanmış bir özellik dalında geçmişi yeniden yazmamak (rebase) önemlidir, çünkü bu, yorumlardaki belirli commit'lere olan bağlantıları bozar.

# İnceleyenin yorumlarına göre değişiklik yap
git checkout feature/biometric-auth
# kodu düzelt
git commit -m "fix: handle biometric timeout per review"
git push

# PR otomatik olarak güncellenecek
# Onaydan sonra — GitHub arayüzü aracılığıyla PR'ı birleştir

Kod İnceleme Süreci

Kod incelemesi, Pull Request'in merkezi bir öğesidir. İnceleyen, değişiklikleri doğruluk, kod stili, güvenlik ve mimari tutarlılık açısından kontrol eder. Kaliteli bir inceleme yalnızca hataları önlemekle kalmaz, aynı zamanda ekip içinde kod tabanı hakkında bilgiyi yayar.

Google'ın Engineering Practices'i (2025) aşağıdaki kod inceleme ilkelerini önerir: inceleyen, değişikliklerin bağlamını anlamalı, genel yorumlar yerine spesifik öneriler vermeli ve teknik ile stilistik yorumları ayırmalıdır. İnceleme süresi, PR'ın oluşturulmasından itibaren 24 saati geçmemelidir.

Mobil geliştirme için kod incelemesi, belirli kontrolleri içerir: targetSdk ile uyumluluk, doğru lifecycle işleme (Android) / view lifecycle (iOS), bellek sızıntısı olmaması (LeakCanary, Instruments), koyu tema desteği ve yerelleştirme. Bu kontroller, lint'ler ve Detekt/ktlint aracılığıyla otomatikleştirilebilir.

Yorum Türleri

PR platformları üç tür yorumu destekler: genel (PR'ın tamamına), satır içi (belirli bir kod satırına) ve öneriler (değiştirme kodu ile). Öneriler, değişikliği tek tıklamayla uygulamaya olanak tanır, süreci hızlandırır ve yineleme sayısını azaltır.

Tüm yorumlar çözüldükten ve CI kontrolleri geçtikten sonra, inceleyen bir onay (Approved) gönderir. PR birleştirilebilir. GitHub ve GitLab, dal koruma kurallarını destekler: gerekli onay sayısı, zorunlu CI kontrolleri ve PR olmadan main'e push yasağı. Mobil projeler için dal koruması ayrıca derleme doğrulamasını da içerir: uygulama derlenmezse (gradle build failed / xcodebuild failed) PR birleştirilemez.

PR'da Çakışma Çözümü

Birleştirme çakışmaları, Pull Request'te aktif ekip çalışmasında yaygın bir durumdur. Platformlar, web arayüzü aracılığıyla çakışma çözümü sunar (basit çakışmalar için) veya yerel olarak çözmeyi önerir. GitHub Actions, özellik dalına her push'ta otomatik olarak birleştirilebilirliği kontrol eder ve birleştirme mümkün değilse PR'ı çakışmalı olarak işaretler.

Pull Request En İyi Uygulamaları

Etkili Pull Request'ler kod incelemesini hızlandırır ve hata sayısını azaltır. SmartBear (2025) tarafından yapılan bir araştırma, 200 satıra kadar koda sahip PR'ların, 1000 satırın üzerindeki PR'lara göre 2 kat daha fazla anlamlı yorum aldığını ve inceleme süresinin 3 kat azaldığını göstermiştir.

• Küçük PR'lar — optimal boyut 100-300 satırdır. Büyük PR'ları mantıksal parçalara bölün: her PR bir görevi çözer. Bu, incelemeyi basitleştirir ve çakışma olasılığını azaltır
• Net açıklama — Conventional Commits'e göre başlık (feat:, fix:, refactor:), gövde “nasıl” yerine “ne ve neden” içerir (kod kendini anlatır). Şablon: hedef → değişiklikler → testler → ilgili issue'lar
• Hızlı geri bildirim — 24 saat içinde inceleme. PR bir günden fazla beklerse, ekip bağlamı kaybeder ve birleştirme çakışmalarının sayısı artar
• Otomasyon — lint'ler, biçimlendiriciler ve testler, PR oluşturulduğunda otomatik olarak çalışmalıdır. Kırmızı CI kontrolleri olan PR'ların birleştirilmesine izin vermeyin
• Draft PR — erken mimari tartışması için kullanın. Draft PR inceleme gerektirmez ve birleştirilemez, ancak erken aşamada kodu meslektaşlara göstermeye olanak tanır

Ek uygulamalar: Cuma akşamı PR oluşturmayın (Pazartesiye kadar kimse inceleme yapmaz), 1-2 kişiden inceleme isteyin (daha fazlası kaliteyi artırmadan süreci yavaşlatır), birleştirmeden önce geçmişi sıkıştırmak için squash merge kullanın. Mobil projeler için, PR açıklamasına test derlemesi bağlantısı (Firebase App Distribution / TestFlight) eklenmesi de önerilir, böylece inceleyen değişiklikleri çalışan uygulamada doğrulayabilir.

Farklı Platformlarda Pull Request

Pull Request'lerle çalışmak için ana platformlar GitHub, GitLab ve Bitbucket'tır. Ortak konsepte rağmen, her birinin ekip için araç seçerken dikkate alınması gereken özellikleri vardır.

GitHub, en büyük topluluğa, CI/CD için Actions'a ve geniş bir uygulama ekosistemine (GitHub Marketplace) sahip en popüler platformdur. GitLab, entegre CI/CD ve tam kendi barındırmalı dağıtım yeteneği ile öne çıkar. Bitbucket, Jira ve Atlassian ekosistemiyle sıkı entegre olup kurumsal ortamlarda popülerdir.

Mobil geliştirme için platform seçimi genellikle CI/CD yeteneklerine göre belirlenir: GitHub Actions, iOS derlemeleri için macOS çalıştırıcılarını destekler, GitLab'ın iOS/Android için yerleşik çalıştırıcıları vardır, Bitbucket Firebase Test Lab ile iyi entegre olur. Platformdan bağımsız olarak PR süreci aynı kalır: dal → inceleme → CI → birleştirme.