Pull request oluşturma ve birleştirme

Bu makalede Pull Request'in (PR) ne olduğunu, neden değişiklikleri tartışmaya yarayan bir araç olduğunu öğrenecek, PR'ları doğrudan IDE'den oluşturmayı ve incelemeyi de göreceksiniz. Bir de iyi commit için üç kuralı ele alacağız. Bu temel bilgiler önemli: Claude Code sizin için pull request hazırlayıp yorum yapabilir. Bu özelliği bilinçli kullanmak için PR'ın ne olduğunu ve ne işe yaradığını anlamanız gerekir.

Örnekler ve arayüz görüntüleri JetBrains IDE'lerine aittir; eylemlerin adları ve konumları kullandığınız sürümde farklı olabilir. Alıştırmalar için ayrı bir eğitim repository'si kullanın. Gerçek bir iş projesinde ise o projenin branch, commit ve değişiklikleri gönderme kurallarına uyun.

Pull request'ler neden kullanılır

Ekipte, değişiklikleri ortak branch'e almadan önce tartışmak faydalıdır. Pull request, önerilen diff'i, yorumları ve kontrol sonuçlarını tek bir yerde toplar. Kişisel projelerde de birleştirmeden önce kendi çalışmanızı gözden geçirmek için kullanabilirsiniz.

PR sürecinde önce bir birleştirme önerisi oluşturursunuz. GitHub'da buna Pull Request, bazı diğer platformlarda ise Merge Request denir. İzlenecek yöntemi ekip belirler.

Pull Request, "lütfen değişikliklerimi kendi branch'imden çekin (pull) ve ana branch'e ekleyin (merge)" anlamına gelen resmî bir istektir. Ancak yalnızca bir istek değildir; kodun main'e girmeden önce tartışıldığı, kontrol edildiği ve iyileştirildiği bir alandır.

Pull request için standart iş akışı

Yeni bir özellik geliştirirken izlenen tipik süreci adım adım inceleyelim.

Branch oluşturmadan önce kaynak branch'i ve GitHub'daki hedef branch'e göre commit listesini kontrol edin. Yeni PR'a ilgisiz yerel commit'ler dahil olmamalı. "Eşitleme" uğruna bunları otomatik göndermeyin: görev için doğru tabanı seçin ve önceki çalışmanızı ayrı tutun.

Adım 1. Yeni görev için bir branch oluşturun. Buradaki PR sürecinde işe ayrı bir branch ile başlanıyor. Diyelim ki katkıda bulunanlar için kuralları içeren bir dosya eklemek istiyoruz; feature/add-contribution-guide branch'ini oluşturalım.

Adım 2. Değişiklikleri yapıp branch'i GitHub'a gönderin. Yeni branch'te CONTRIBUTING.md dosyasını oluşturun (oluşturduktan sonra Add'e tıklayın) ve diğer geliştiricilere bir not yazın. Ardından Commit and Push işlemini anlaşılır bir mesajla tamamlayın; örneğin docs: Add contribution guide.

Bu kritik bir adımdır. Pull Request, uzak sunucuda zaten bulunan bir branch üzerinden oluşturulur. Bu nedenle PR oluşturmadan önce yeni branch'i mutlaka GitHub'a göndermeniz (push) gerekir.

IDE'den Pull Request oluşturma

Karşılaştırmanın iki tarafını da kontrol edin: base, değişikliklerin önerildiği branch; compare/head ise çalışmanızın bulunduğu branch'tir. PR oluşturmadan önce commit listesini ve diff'i inceleyin.

Branch'iniz artık GitHub'da olduğuna göre Pull Request oluşturabilirsiniz.

Adım 1. Pull Requests sekmesini açın. IDE'nin sol kenar çubuğunda Pull Requests sekmesini bulun. Açıp + simgesine (veya Create Pull Request düğmesine) tıklayın.

Adım 2. PR bilgilerini doldurun. IDE kullanışlı bir arayüz açar. Burada bilgileri doğru şekilde girmeniz gerekir. Temel alanlar:

1. başlık - IDE buraya çoğu zaman branch adını veya son commit mesajını koyar; başlığın kısa, anlaşılır ve değişiklikleri yansıttığından emin olun;
2. açıklama - ne yaptığınızı ve neden yaptığınızı ekip arkadaşlarınıza ayrıntılı biçimde anlatın;
3. inceleyiciler (Reviewers) - değişiklikleri kontrol etmelerini istediğiniz kişiler. Onay gerekip gerekmediğini repository kuralları belirler;
4. atananlar (Assignees) - genellikle burada yazar ve inceleme sonrasındaki düzenlemelerden sorumlu kişi olarak kendinizi seçersiniz.

Create Pull Request'e tıklamadan önce base, head ve diff'i bir kez daha kontrol edin. Çalışmanız incelemeye hazır değilse Draft PR oluşturabilirsiniz; tabii bu seçenek mevcutsa. Normal PR da taslak PR da repository'ye erişimi olan kişiler tarafından görülebilir.

Kod incelemesi: kontrol ve tartışma

PR oluşturulduktan sonra en önemli aşama olan kod incelemesi başlar. Ekip arkadaşlarınız PR'ı açıp tüm değişikliklere bakabilir ve yorum bırakabilir.

Tüm tartışmaları IDE'deki Pull Requests sekmesinde görebilirsiniz. Biri kod satırına yorum bırakırsa bildirim alırsınız; tarayıcıya geçmeden yanıt verebilirsiniz.

Düzenleme istenirse ne yapmalısınız? Çok basit: yeni bir PR oluşturmanız gerekmez. Bu PR'ın kaynak branch'inde kodu düzenleyin, yeni bir commit oluşturup gönderin. GitHub'daki Pull Request, yeni commit'leri var olan tartışmaya ekleyerek otomatik güncellenir.

İşi tamamlama: branch'i birleştirme ve silme

Tüm yorumlar giderilip ekip değişiklikleri onayladığında (bir "approval" aldığınızda) Pull Request'i birleştirebilirsiniz. Genellikle bunu kıdemli geliştirici yapar; repository'de yetkiniz varsa siz de yapabilirsiniz.

Adım 1. Birleştirme. Yorumları, zorunlu onayları ve kontrollerin durumunu gözden geçirin. Kurallar ve izinler birleştirmeye olanak tanıyorsa proje kurallarına göre kullanılabilir yöntemi (merge, squash veya rebase) seçip onaylayın. Değişiklikler PR'ın hedef branch'ine, bu örnekte main'e, eklenir.

Adım 2. Branch'i silme. Birleştirmeden sonra feature branch'e gerek kalmaz. Repository'yi gereksiz branch'lerle doldurmamak için silmekte fayda var. GitHub, Delete branch düğmesiyle bunu zaten önerir.

Birleştirmeden sonra yerel olarak main'e geçin, güncellemeleri alın ve PR'daki değişikliklerin orada olduğunu doğrulayın. Gerekli bir çalışma kalmadıysa yerel görev branch'ini silebilirsiniz. IDE normal yöntemle silmeye izin vermiyorsa, özellikle squash veya rebase sonrasında önce nedenini öğrenin.

İyi bir commit için üç kural

İyi bir commit yalnızca doğru mesajdan ibaret değildir; içeriği de doğru olmalıdır. Değişiklik geçmişini temiz ve kullanışlı tutmak için şu üç basit kurala uyun.

Kural 1: anlaşılır commit mesajları yazın

Commit'leriniz ekibe ve gelecekteki kendinize bıraktığınız notlardır. Yalnızca "fix" ya da "update" mesajlarından oluşan bir geçmiş işe yaramaz. Yaygın biçimlerden biri Conventional Commits'tir. Önerdiği yapı şöyledir:

<tür>: <kısa açıklama>

Tür, değişiklik kategorisini açıklayan kısa bir kelimedir:

• feat - yeni özellik;
• fix - hata düzeltmesi;
• docs - dokümantasyon değişiklikleri;
• style - mantığı etkilemeyen biçimlendirme düzenlemeleri;
• refactor - yeni özellik veya hata düzeltmesi içermeyen kod değişiklikleri;
• test - test ekleme veya düzeltme;
• chore - rutin işler (bağımlılıkları güncelleme, build ayarları).

Örnekler:

• Kötü: fixed bug
• İyi: fix: Correct user login validation
• Kötü: readme
• İyi: docs: Update installation instructions

Kural 2: tek commit, tek mantıksal değişiklik

Bir commit'e hata düzeltmesini, yeni bir özelliği ve eski kodun refactoring'ini sığdırmaya çalışmayın. Böyle bir commit'i incelemek zordur ve sorunsuz biçimde geri almak neredeyse imkânsızdır. Her commit tek ve belirli bir işi çözmelidir.

• Kötü: avatar alanı ekleyen, ad doğrulamasını düzelten ve düğme renklerini değiştiren tek bir "Update user page" commit'i;
• İyi: üç ayrı commit:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. feat: Update button colors on user page

Çalışırken tek bir dosyada gereğinden fazla değişiklik yaptıysanız, IDE sizi dosyanın tamamını commit etmek zorunda bırakmaz. Commit penceresinde dosyayı genişletip yalnızca bu görevle ilgili parçalara (chunks) onay işareti koyabilirsiniz.

Kural 3: değişikliklerin sonucunu kontrol edin

Birleştirmeden önce değişikliğe uygun kontrolleri çalıştırın ve gerçek sonuçlarına bakın. Dokümantasyon düzenlemesiyle yeni bir mantık için gereken kontroller farklıdır.

Repository'de otomatik kontroller zaten ayarlıysa PR bunların durumunu gösterir. Yeşil işaret, çalıştırılan belirli kontrollerin başarılı olduğunu belirtir; hata olmadığını kanıtlamaz. Nelerin çalıştırıldığını ve nelerin kontrol edilmediğini inceleyin. Otomasyon kurulumu ayrı bir konudur.

Claude Code ile birlikte çalışma

PR, Claude Code'un özellikle faydalı olduğu bir noktadır. Şunlara dikkat edin:

• Claude, branch'iniz için başlık ve açıklaması hazır bir pull request oluşturabilir; GitHub'da PR oluşturmadan önce metni kontrol edersiniz;
• PR'daki değişiklikleri gözden geçirip ilk bakış olarak yorum bırakabilir;
• proje kurallarına uygun commit mesajları hazırlamanıza yardımcı olabilir;
• önceden ayarlanmış kontrollerin sonuçlarını okumanıza ve kontrol edilmemiş noktaları belirtmenize yardımcı olabilir.

Önceki makale: Git'te branch'ler ve birleştirme · Sonraki makale: Git'te değişiklikleri geri alma ve kurtarma