Yasin Ateş | Frontend Developer, Web & Müzik

Bir PR açıyorsunuz, açıklama yok. Reviewer bakıyor, “bu neyi çözüyor?” diye yazıyor. Siz cevaplayana kadar yarım gün geçiyor. 😁 Reviewer ne bakacağını bilmiyor, author ne yazacağını bilmiyor. Bu yazıda PR template’i sıfırdan nasıl kurarsınız, code review sürecini nasıl sistematik hale getirirsiniz ve otomasyonla bu süreci nasıl güçlendirirsiniz, hepsini adım adım ele alacağız.

İlk başta sorunu anlayalım. Bir geliştirici sabah 09:00'da bir PR açıyor. Başlık: "fix". Açıklama: boş. Değiştirilen dosya sayısı: 84

Reviewer ne yapacak, yapılan işin kapsamı ne? Hiç bir şey belli değil

İşte tam bu noktada PR template ve yapılandırılmış bir code review süreci devreye giriyor.

🧩 PR Template Nedir ve Neden Önemlidir?

PR template, bir pull request açıldığında otomatik olarak description alanına yüklenen, önceden tanımlanmış bir Markdown dosyasıdır.

Her yeni PR açıldığında şu sorular otomatik olarak karşınıza çıkıyor;

Bu PR ne yapıyor?
Neden bu değişikliği yapıyoruz?
Nasıl test edildi?
Reviewer’ın özellikle bakması gereken yer var mı?

PR Template Yokken:

Bir PR açılıyor, başlık "update button styles", açıklama boş. Reviewer 15 dakika diff'e bakıyor, neden bu değişikliğin yapıldığını anlayamıyor, geliştirmeyi yapana soruyor, cevap 2 saat sonra geliyor.

PR Teamplate Varken:

Aynı PR açılıyor ama bu sefer description alanında şunlar yazıyor: “Tasarım ekibi tarafından butonların contrast ratio’sunun WCAG 2.1 AA standardını karşılamadığını raporlandı. Renk değerleri güncellendi ve Storybook’ta görsel test yapıldı.” Reviewer 3 dakikada context’i anlıyor, direkt koda odaklanıyor.

🧱 PR Template Tasarımı: Reviewer’ın İhtiyacı Olan Bilgi

PR template yazarken, Reviewer PR’ı açtığında 60 saniye içinde şu 3 soruya cevap bulmalı.

Ne değişti?
Neden değişti?
Nasıl test edildi?

Şimdi adım adım basit bir PR template oluşturalım;

🛠️ Adım Adım PR Template Oluşturma

Hadi adım adım ilerleyelim. GitHub, belirli bir klasör yapısındaki Markdown dosyasını otomatik olarak PR description’ına yükler.

Adım 1: Dosya Yapısını Kur

Reponuzun kök dizininde .github klasörü oluşturun ve içine PULL_REQUEST_TEMPLATE.md dosyasını ekleyin.

mkdir -p .github
touch .github/PULL_REQUEST_TEMPLATE.md

mkdir -p .github: .github klasörünü oluşturur; zaten varsa hata vermez.
touch: Boş bir Markdown dosyası oluşturur.

💡 Ben makalede anlatırken Github üzerinden anlatım ama Gitlab, Bitbucket gibi diğer platformlarda da uygulanabilir. Önemli olan içerisinde açıklama olan bir template 😅 Diğer platformlar için ufak bir araştırma ile ilgili dosyanın ismini kolayca bulabilirsiniz

Adım 2: Template İçeriğini Yazalım

Şimdi bu dosyanın içeriğine odaklanalım. Aşağıda gerçek dünyada kullandığım ve işe yarayan bir template var:

## 📋 Bu PR Ne Yapıyor?

<!-- Değişikliği kısaca açıkla. "Ne" sorusunu yanıtla. -->

## 🎯 Neden Bu Değişikliği Yapıyoruz?

<!-- Motivasyonu açıkla. İlgili ticket/issue linkini ekle. -->

Closes #

## 🧪 Nasıl Test Edildi?

<!-- Hangi test senaryolarını çalıştırdın? Manuel mi, otomatik mi? -->

- [ ] Unit test yazıldı / güncellendi
- [ ] Manuel test yapıldı
- [ ] Mevcut testler başarıyla geçiyor

## 📸 Ekran Görüntüsü / Video (UI değişikliği varsa)

<!-- UI değişikliği içeren PR'larda önce/sonra görseli ekle. -->

## ⚠️ Reviewer'ın Dikkat Etmesi Gereken Noktalar

<!-- Özellikle gözden geçirilmesini istediğin kısımlar var mı? -->

## 📦 Bağımlılık / Konfigürasyon Değişikliği

- [ ] Environment variable eklendi/değiştirildi
- [ ] Package bağımlılığı eklendi/kaldırıldı
- [ ] Migration gerekiyor

Kritik noktalara dikkat edelim:

Closes # satırı: GitHub bu syntax'ı tanır ve PR merge edildiğinde ilgili issue'yu otomatik kapatır. (Eğer Github değil de başka platformlar kullanıyorsanız, Gitlab, Bitbucket gibi, ufak bir araştırma yapmanız gerekebilir, otomatik issue kapatmaya izin veriyor mu, izin veriyorsa ne istiyor gibi…)
HTML yorum satırları (): Author'a rehberlik eder ama PR açıldığında render'da görünmez.
Checkbox’lar: Author’ı adım adım düşünmeye zorlar; aynı zamanda reviewer için hızlı bir durum özeti sağlar.

Adım 3: Birden Fazla Template (Opsiyonel)

Farklı PR tipleri için farklı template’ler de tanımlayabilirsiniz. Örneğin feature ve hotfix için ayrı template'ler:

mkdir -p .github/PULL_REQUEST_TEMPLATE
touch .github/PULL_REQUEST_TEMPLATE/feature.md
touch .github/PULL_REQUEST_TEMPLATE/hotfix.md

Bu durumda PR açarken URL’e ?template=feature.md parametresini ekleyerek ilgili template'i yükleyebilirsiniz.

# Örnek GitHub PR URL'i
https://github.com/kullanici/repo/compare/main...feature-branch?template=feature.md

?template=feature.md: GitHub'a hangi template'i yükleyeceğini belirtir.

📋 Review Checklist: Nelere Bakmalıyız?

Review sırasında sistematik olmak için aşağıdaki kategorilere göre ilerlemek faydalı olabilir

Fonksiyonellik

★ Kod, PR description’da tanımlanan işi gerçekten yapıyor mu?
★ Edge case’ler düşünülmüş mü?
★ Hata yönetimi (error handling) yeterli mi?
★ Geriye dönük uyumluluk (backward compatibility) korunmuş mu?

Kod Kalitesi

★ Fonksiyon ve değişken isimleri anlamlı mı? (Örneğin proje genelinde onSubmit veya handleSubmit gibi ön ekler ile kullanılıyorsa fonksiyonlar geliştirme buna uygun yapılmış mı?)
★ Tek sorumluluk prensibine (Single Responsibility Principle) uyuluyor mu?
★ DRY (Don’t Repeat Yourself) prensibine uyuluyor mu?
★ Magic number veya hardcoded string var mı? (Hardcoded string yerine genelde proje genelinde kullanılan stringler için ortak bir Constant dosyası olması iyi olur)

Güvenlik

★ Kullanıcı girdisi validate ediliyor mu?
★ Hassas veri (şifre, token, API key) log’a yazılıyor mu? veya Env dosyası yanlışlıkla Git’e pushlanmış mı? (Eğer pushlandıysa git-filter-repo gibi araçlar ile git geçmişinden silinmesi gerekebilir)
★ SQL injection, XSS gibi güvenlik açıklarına karşı önlem alınmış mı? (ORM vb şeyler kullanılmış mı?)
★ Authorization kontrolü doğru yapılmış mı?

Performans

★ Gereksiz re-render veya hesaplama var mı? (React’ten örnek verecek olursam, useMemo, useCallback vb şeyler kullanılmış mı?)
★ N+1 query problemi oluşuyor mu?
★ Büyük veri setleriyle nasıl davranır?
★ Cache kullanımı değerlendirilmiş mi?

Test

★ Kritik senaryolar için test yazılmış mı? (Özellikle Happy path olan kısımlar için)
★ Testler anlamlı mı, yoksa coverage doldurmak için mi yazılmış?
★ Mevcut testler hâlâ geçiyor mu?

🤖 Otomasyonlar: CODEOWNERS, Label, PR Size Guard, Auto-Assign

Doğru kişiye review gitsin
PR doğru etiketlensin
PR çok büyürse uyarı verilsin
Review otomatik assign edilsin

Adım 1: CODEOWNERS ile ownership tanımlayın

CODEOWNERS, belirli dosya veya klasör değiştiğinde otomatik reviewer atayan GitHub özelliği.

Önce .github/CODEOWNERS dosyasını ekleyelim:

# .github/CODEOWNERS

# Frontend
/apps/web/ @frontend-team

# Backend
/apps/api/ @backend-team

# Payments kritik
/apps/api/src/payments/ @payments-squad

# DevOps
/.github/ @devops-team

Klasör bazlı ownership, “kim review edecek?” sorusunu ortadan kaldırır.
Kritik modüllerde (payments gibi) daha dar bir ownership tanımı riskinizi düşürür.

Adım 2: actions/labeler ile otomatik label

actions/labeler, dosya yollarına göre PR’a otomatik label basan resmi GitHub Action’ıdır.

Önce label kurallarını yazalım:

# .github/labeler.yml
frontend:
 - changed-files:
 - any-glob-to-any-file: "apps/web/**"

backend:
 - changed-files:
 - any-glob-to-any-file: "apps/api/**"

devops:
 - changed-files:
 - any-glob-to-any-file: ".github/**"

Sonra workflow ekleyelim:

# .github/workflows/labeler.yml
name: Labeler

on:
 pull_request:

permissions:
 contents: read
 pull-requests: write

jobs:
 label:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/labeler@v5
 with:
 repo-token: "${{ secrets.GITHUB_TOKEN }}"
 configuration-path: ".github/labeler.yml"

pull-requests: write: Action’ın label yazabilmesi için gerekli.
configuration-path: Kuralları tek bir yerde tutarsınız.

Adım 3: PR size labeler ile “büyük PR” problemini azaltın

PR büyüklüğünü otomatik etiketlemek, hem PR sahibine hem reviewerlara “bu PR riskli olabilir” sinyali verir.

Örnek olarak pascalgn/size-labeler kullanabilirsiniz. Bu action, PR diff boyutuna göre label basar.

# .github/workflows/pr-size.yml
name: PR Size

on:
 pull_request:

permissions:
 pull-requests: write

jobs:
 size:
 runs-on: ubuntu-latest
 steps:
 - uses: pascalgn/size-labeler@v0.4.3
 env:
 GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
 with:
 sizes: |
 {
 "XS": 50,
 "S": 150,
 "M": 400,
 "L": 800,
 "XL": 2000
 }

sizes: Ekip olgunluğunuza göre eşikleri ayarlayın.
Label’ları branch protection gibi zorunlu yapmayın, burada amaç uyarı vermek.

Adım 4: Auto-assign ile review beklemeyi kısaltın

Reviewer ataması unutuluyorsa, kentaro-m/auto-assign-action gibi bir action ile otomatik atayabilirsiniz.

Önce config:

# .github/auto_assign.yml
addReviewers: true
addAssignees: author

reviewers:
 - reviewer1
 - reviewer2

numberOfReviewers: 1

Sonra workflow:

# .github/workflows/auto-assign.yml
name: Auto Assign

on:
 pull_request:
 types: [opened, ready_for_review, reopened]

jobs:
 auto-assign:
 runs-on: ubuntu-latest
 steps:
 - uses: kentaro-m/auto-assign-action@v2.0.0
 with:
 configuration-path: ".github/auto_assign.yml"

Burada kritik satırlar:

types: [opened, ready_for_review]: Draft’tan çıkınca da reviewer atanır.
numberOfReviewers: Ekibi kilitlemeden, minimum review garantisi sağlar.

✅ Son Kontrol: Repo Bazlı Hızlı Checklist

Aşağıdaki listeyi repo README’sine bile koyabilirsiniz.

.github/pull_request_template.md var
Branch protection açık (approval + required checks)
CI workflow PR’da çalışıyor
CODEOWNERS tanımlı
Otomatik label var (frontend, backend gibi)
PR size label var

Buraya kadar kurduysanız, PR süreciniz “kişiye bağlı” olmaktan çıkar. Sistem çalışır.

🚀 Github PR Template Örnekleri

Son olarak PR template’ler ekipten ekibe değişse de ben bildiğim bazı public olan Github Template örneklerinin linklerini bırakayım. Kullanmak isterseniz inceleyip kendi ekibizine uydurabilirsiniz;

📬 Geri Bildirim

Makaleyi yazarken, kaynakları belirleme ve araştırma için kendi notlarımı, yazım denetimi ve ek araştırma için Claude Sonnet 4.6, GPT 5.2 High modellerini kullandım. Resimleri üretmek için ise Gemini 3 Pro Preview 2k (Nano Banana Pro) modelini kullandım.

Yazı ile ilgili tavsiye, öneri, eleştirileri dikkate alıyorum. İletişime geçmek isterseniz bana websitemdeki sosyal medya adreslerimden veya Linkedin üzerinden ulaşabilirsiniz.

Sevgiyle kalın, Yasin 🤗

📚 Makaleyi Yazarken Kullandığım Kaynaklar

GitHub Docs — Pull Request Templates — PR template oluşturma adımları için resmi kaynak
GitHub Actions Dokümantasyon — Workflow yapılandırması için resmi kaynak
Google Engineering Practices — Code Review — Google’ın code review rehberi; reviewer ve author perspektiflerini ele alıyor
Conventional Comments — Review comment’lerini yapılandırmak için kullanışlı bir standart
GitHub Docs — CODEOWNERS — Ownership ve otomatik reviewer atama mantığı için
GitHub Actions Documentation — CI workflow tasarımı için
actions/labeler — Dosya yoluna göre otomatik label basmak için
pascalgn/size-labeler — PR diff boyutuna göre otomatik size label basmak için
kentaro-m/auto-assign-action — PR açılınca otomatik reviewer atamak için

PR Template ve Code Review Sürecini İyileştirme