GitHub'da pull request açmak ve kod incelemeyi yürütmek

Pull request nedir, hangi sorunu çözer?

Pull request (PR), bir daldaki değişikliklerin başka bir dala (genellikle ana dala) alınması için yapılan öneridir. Değişiklik doğrudan ana dala yazılmak yerine bir tartışma ve doğrulama sürecinden geçer. Bu süreçte hatalar birleşmeden önce yakalanır, bilgi ekip içinde paylaşılır ve değişikliğin nedeni kayıt altına alınır.

PR yalnızca bir onay kapısı değildir; aynı zamanda bir iletişim aracıdır. Neyin neden değiştiğini, nasıl test edildiğini ve nelerin kapsam dışı bırakıldığını anlatan bir belgedir. Aylar sonra bir davranışın neden değiştiğini anlamak isteyen biri, çoğu zaman kod yerine PR tartışmasında cevabı bulur. Bu nedenle iyi bir PR hem kodu hem bağlamı taşır.

Pull request nasıl açılır? Adımlar

Akış şöyledir:

• Ana daldan yeni bir özellik dalı açın: git switch -c feature/sepet-kuponu
• Değişiklikleri küçük ve anlamlı işlemelerle kaydedin
• Dalı uzak depoya gönderin: git push -u origin feature/sepet-kuponu
• GitHub'da dalın yanında beliren "Compare & pull request" önerisinden ya da Pull requests sekmesinden yeni PR oluşturun
• Hedef dalı, başlığı ve açıklamayı yazın, inceleyenleri atayın

Henüz hazır olmayan ama erken geri bildirim istediğiniz işler için taslak (draft) PR açabilirsiniz; taslak PR birleştirilemez ve inceleyenlere "bu henüz bitmedi" mesajını verir. Hazır olunca "ready for review" durumuna alırsınız. PR açıldıktan sonra o daldaki yeni işlemeler PR'a otomatik eklenir; yani inceleme geri bildirimine yanıt vermek için aynı dalı güncellemeniz yeterlidir.

İyi bir PR açıklaması neleri içerir?

Başlık değişikliği tek cümleyle anlatmalı ve ne yaptığını söylemelidir. "Düzeltmeler" yerine "Sepette kupon kodu doğrulamasını sunucu tarafına taşı" gibi. Açıklama ise inceleyenin sorularını önceden yanıtlar:

• Neden: sorun ya da gereksinim nedir, ilgili iş kaydı bağlantısı
• Ne: yapılan değişikliğin kısa özeti ve seçilen yaklaşım
• Nasıl test edildi: elle ve otomatik testler, ekran görüntüsü ya da çıktı
• Riskler ve kapsam dışı kalanlar
• İnceleyenin özellikle bakmasını istediğiniz yerler

Bir PR şablonu (depodaki pull request şablon dosyası) bu başlıkları her yeni PR'da hazır getirir ve ekip standardını kendiliğinden oluşturur. Küçük PR'lar daha hızlı ve daha dikkatli incelenir; çok dosyalı ve çok amaçlı bir PR'ı incelemek hem zordur hem de hataların gözden kaçma olasılığını artırır. Değişikliği mümkünse tek amaca odaklayın.

Kod inceleme nasıl yapılır?

İnceleyen önce açıklamayı okuyup değişikliğin amacını anlar, sonra dosyalara bakar. İncelemede sorulacak sorular: Değişiklik amacına ulaşıyor mu? Hata durumları, sınır değerleri ve güvenlik düşünülmüş mü? Testler değişikliği gerçekten kapsıyor mu? Kod okunabilir ve mevcut düzenle tutarlı mı? Performans ya da bakım yükü getiriyor mu?

Geri bildirimde bir satıra yorum bırakılır; birden fazla yorum "review" olarak toplanıp bir kararla gönderilir: yorum, onay (approve) ya da değişiklik talebi (request changes). Yorumlar yapıcı ve somut olmalıdır: kişi yerine koda odaklanın, sebebini yazın ve mümkünse öneri sunun. GitHub'ın öneri (suggestion) özelliği küçük düzeltmeleri doğrudan uygulanabilir hâle getirir. Zorunlu düzeltmelerle "isteğe bağlı" tavsiyeleri ayırmak, yazarın neye öncelik vereceğini bilmesini sağlar.

Otomatik kontroller ve branch koruması

İnsan incelemesi, otomatik kontrollerle birlikte çalışır. PR açıldığında derleme, birim testleri, kod stili ve güvenlik taraması gibi işler otomatik çalışabilir (örneğin GitHub Actions ile). Sonuçlar PR sayfasında durum kontrolleri olarak görünür.

Depo yöneticisi ana dal için koruma kuralları tanımlar: doğrudan gönderimi engellemek, birleştirme öncesi zorunlu onay sayısı belirlemek, durum kontrollerinin geçmesini şart koşmak, yeni işlemede eski onayı geçersiz saymak ve konuşmaların çözülmesini istemek gibi. CODEOWNERS dosyası ile belirli klasörler için otomatik inceleyici atanır; böylece ödeme kodunu ödeme ekibinin onaylaması sağlanır. Bu kurallar tek tek kişilerin dikkatine bağımlı olmadan kalite eşiği oluşturur.

Birleştirme seçenekleri ve sonrası

GitHub birleştirme için şu biçimleri sunar: normal merge işlemesi, squash ve rebase. Normal birleştirme dalın geçmişini korur ve bir birleştirme işlemesi ekler. Squash, dalın tüm işlemelerini tek işleme olarak ana dala alır; çok sayıda küçük düzeltme işlemesi içeren dallar için geçmişi sadeleştirir. Rebase seçeneği işlemeleri doğrusal olarak ana dalın ucuna ekler. Ekibin tercihi depo ayarlarında kısıtlanabilir.

Birleştirmeden sonra uzak dal silinerek depo temiz tutulur; GitHub bunu tek tıkla ya da otomatik yapabilir. Birleştirilen PR bir iş kaydına bağlıysa, açıklamada "closes" gibi anahtar kelimelerle kaydın otomatik kapanması sağlanabilir. Birleştirme sonrası ana dalın derlendiğini ve dağıtım hattının sorunsuz çalıştığını doğrulamak da süreci tamamlar.

Sık yapılan hatalar ve alışkanlıklar

Sık hatalar: devasa PR açmak, açıklamayı boş bırakmak, geri bildirime savunmacı yaklaşmak, incelemeyi sadece onay damgası olarak görmek ve incelemeyi günlerce bekletmek. Bekleyen PR, yazarın başka işe geçmesine ve bağlamı kaybetmesine yol açar; ekipçe incelemeye yanıt süresi için bir beklenti belirlemek yararlıdır.

Geri bildirim verirken tonu yumuşak, içeriği net tutun; yazar geri bildirim alırken kodun kişiye değil sürece ait olduğunu hatırlasın. İncelemeyi yalnızca hata aramak olarak değil, öğrenme ve bilgi paylaşımı olarak görün: iyi yazılmış bir bölümü belirtmek de geri bildirimdir. Son olarak, tekrar eden yorumlar (stil, adlandırma) varsa bunları insan incelemesinden çıkarıp otomatik denetime devredin.

Bu beceri Mindset programlarında nerede çalışılır?

Mindset'in GIT ve GITHUB Uzmanlığı Eğitimi, GitHub ile işbirliği ve proje yönetimi, branch yönetimi ve merge işlemleri ile GitHub Actions ile CI/CD başlıklarını içerir. Pull request akışı ve kod inceleme, bu başlıkların kesiştiği ekip pratiğidir. Eğitim yazılım geliştiricilere, ayrıca depo yönetimi ve inceleme standardı belirleyen teknik liderlere uygundur.

Kurumsal yazılım ekipleri için PR şablonu, branch koruması ve inceleme beklentilerinin ortak tanımlanması, kalite ve teslim hızını dengelemeye yardımcı olur.