GitHub Kolaborasyon İçin İpuçları

Tek başına kod yazarken her şey basit. Branch adı ne olursa olsun, commit mesajı "fix" bile olsa çalışır. Takıma girdiğin an bu rahatlık biter. Kodun artık okunması, tartışılması ve onaylanması gerekir. İşte tam bu noktada github pull request code review döngüsü devreye girer.

Aşağıdaki adımları kendi hesabında test edebilirsin. Boş bir repo aç, iki branch oluştur, süreci baştan sona yürüt. Okumak yetmez; bir kez uygulayınca mantığı oturuyor.

Pull Request Açmadan Önce Yapılacaklar

İyi bir pull request, açılmadan önce kazanılır. Review sırasında çıkan yorumların çoğu, hazırlık aşamasında engellenebilir.

Branch'i doğru kurmak

• Her iş için ayrı branch aç. Tek branch'te üç farklı konu ilerletmek review'ı imkânsızlaştırır.
• Branch adını konuşan bir isim yap: feature/kullanici-profili, fix/login-hatasi gibi.
• Branch'i her zaman güncel ana daldan başlat. Önce git pull, sonra git switch -c.
• Uzun süren işlerde ara ara ana dalı branch'ine çek. Bekletirsen çatışma birikir. Git Workflow Pratik Rehberi'ndeki rebase kısmı burada işine yarar.

Commit'leri okunabilir hale getirmek

Reviewer commit listesine bakarak ne yaptığını anlamalı. Yığın halinde tek commit atmak zorlar.

• Bir commit, bir mantıklı değişiklik olsun. "Fonksiyonu ekle" ve "testini yaz" ayrı commit olabilir.
• Mesajı emir kipiyle yaz: "Kullanıcı doğrulamasını ekle". Geçmiş zaman kullanma alışkanlığı karışıklık yaratır.
• İlk satırı 50 karakter civarında tut. Detay gerekiyorsa boş satır bırakıp altına yaz.
• Dağınık commit'leri git rebase -i ile birleştir. Deneme yanılma commit'lerini kimse görmek zorunda değil.

PR açıklamasını doldurmak

Boş bir açıklama, reviewer'a "kodu sen çöz" demektir. Şu üç soruya cevap ver:

1. Ne değişti? İki üç maddeyle özetle.
2. Neden değişti? Issue numarasını yaz, bağlamı ver.
3. Nasıl test edilir? Çalıştırma komutunu, test edilecek ekranı veya endpoint'i belirt.

• Arayüz değişikliğinde ekran görüntüsü ekle. Tartışmanın yarısı böyle kapanır.
• İşin bitmediyse draft olarak aç. Erken geri bildirim almanın en temiz yolu.
• PR'ı küçük tut. 400 satırlık bir değişikliğe gelen yorum, 2000 satırlıktan çok daha faydalıdır. Büyük iş varsa parçala.
• Kendi PR'ını önce kendin oku. "Files changed" sekmesinde gezinmek, unuttuğun console.log satırlarını hemen gösterir.

Code Review Sürecini Yürütmek

Review bir sınav değil. Kodun kalitesini yükseltmek ve bilgiyi takıma yaymak için var. İki tarafın da rolü var: yazan ve okuyan.

Yorumları karşılamak

• Her yoruma cevap ver. Kabul ediyorsan uygula, sonra "düzeltildi" yaz.
• Katılmıyorsan gerekçe sun. "Şu senaryoda bu yaklaşım kırılıyor, bu yüzden böyle yaptım" cümlesi tartışmayı ilerletir.
• Düzeltmeleri ayrı commit'lerde gönder. Reviewer sadece yeni commit'lere bakarak kontrol eder.
• Yorumu kişisel algılama. Eleştiri koda gelir, sana gelmez.
• Konu uzuyorsa sohbete taşı. Yedi mesajlık thread'ler genelde beş dakikalık bir konuşmayla çözülür.

Başkasının kodunu incelemek

İyi reviewer olmak, iyi kod yazmaktan daha hızlı öğrenilir. Şu sıralamayı izle:

1. Önce PR açıklamasını oku. Amacı bilmeden koda bakmak zaman kaybı.
2. Değişen dosyaları büyükten küçüğe tara. Mimari kararları ilk gör.
3. Sonra detaya in: isimlendirme, hata yönetimi, sınır durumları.

• Yorumun türünü belirt. öneri:, soru:, blocker: gibi etiketler beklentiyi netleştirir.
• Sadece hata bulma. İyi yazılmış bir bölüme "burası temiz olmuş" demek kültürü besler.
• Stil tartışmasını otomatikleştir. Formatlayıcı ve linter kurulmuşsa boşluk kavgası bitir. VS Code tarafındaki kaydetmede formatla ayarı bu iş için yeterli.
• "Approve", "comment" ve "request changes" arasındaki farkı bilinçli kullan. Küçük bir öneri için değişiklik talep etmek süreci gereksiz yavaşlatır.

Merge ve sonrası

• Testler yeşile dönmeden merge etme. Branch protection kuralıyla bunu zorunlu yapabilirsin.
• Merge sonrası branch'i sil. Repo'da otuz ölü branch tutmanın kimseye faydası yok.
• Yerelde de temizlik yap: git fetch --prune.
• PR'da çıkan tekrar
  © 2026 Yazılım Atölyesi