Git pull request nasıl yapılır? Ekipte branch'ten merge'e adım adım

Bir ekip projesinin ilk haftasında genelde aynı şey olur: Herkes doğrudan main'e push eder, biri diğerinin değişikliğini ezer, kimse hangi kodun neden geldiğini bilmez. Çözüm daha fazla dikkat değil, bir akış.

Kısa cevap şu: Her iş bir issue ile başlar, kendi branch'inde yapılır, pull request ile önerilir, review'dan geçer ve ancak ondan sonra main'e girer.

Aşağıda bu akışı GitHub üzerinden, komutlarıyla adım adım anlatıyoruz. GitLab gibi platformlarda isimler biraz değişir (orada "merge request" denir) ama mantık aynı.

Akışın tamamı

1. Issue aç ya da üstlen
2. Güncel main'den branch aç
3. Küçük commit'lerle çalış
4. Branch'i push et
5. Pull request aç
6. Review al, düzelt
7. Gerekirse branch'i main ile güncelle
8. Merge et ve temizlik yap

1. İşi bir issue'ya bağla

Issue, "ne yapacağız ve ne zaman bitmiş sayılır?" sorusunun yazılı cevabıdır. İyi bir issue üç şey içerir:

• Ne: "Giriş ekranına e-posta doğrulaması ekle"
• Neden: "Boş ya da hatalı e-postayla istek atılıyor, API 400 dönüyor"
• Bitti tanımı: "Geçersiz e-postada form gönderilmiyor, alanın altında hata mesajı çıkıyor"

İşe başlamadan issue'yu kendine ata ya da altına "bunu ben alıyorum" yaz. İki kişinin aynı işi yapması ekipteki en pahalı hatalardan biridir ve Git bunu senin yerine çözemez.

2. Güncel main'den branch aç

Branch'i her zaman güncel main'den aç. Eski bir noktadan açarsan PR'ın, ekibin çoktan değiştirdiği koda göre yazılmış olur.

git switch main
git pull
git switch -c 42-giris-eposta-dogrulama

git switch -c yeni bir branch oluşturur ve seni o branch'e geçirir. Eski kaynaklarda aynı işi yapan git checkout -b komutunu da görürsün.

Branch adına issue numarasını ve kısa bir açıklamayı koymak, bir hafta sonra "bu branch neydi?" sorusunu ortadan kaldırır.

3. Küçük, anlamlı commit'lerle çalış

Commit bir "kaydet" tuşu değil; geri dönülebilir ve açıklanabilir bir adım.

git status
git add -p
git commit -m "Giriş formuna e-posta formatı kontrolü ekle"

git add -p değişiklikleri parça parça gösterir ve her birini commit'e alıp almayacağını sorar. Yanlışlıkla bir hata ayıklama satırını ya da alakasız bir dosyayı commit'lemeni önler.

Commit mesajında ne yaptığını kısa ve net yaz. "fix", "update", "son hali" gibi mesajlar üç hafta sonra senin için bile anlamsızdır.

4. Branch'i push et

git push -u origin 42-giris-eposta-dogrulama

-u ile yerel branch'ini uzaktaki branch'e bağlarsın. Bundan sonra aynı branch'te sadece git push yazman yeter.

5. Pull request aç

Push ettikten sonra GitHub'da repo sayfasında "Compare & pull request" önerisi çıkar. Terminali seviyorsan GitHub CLI ile gh pr create de aynı işi görür.

İyi bir PR açıklaması reviewer'ın işini yarıya indirir:

• Ne değişti? İki üç cümle.
• Neden? İlgili issue'yu bağla.
• Nasıl test edilir? "Uygulamayı aç, e-posta alanına abc yaz, Gönder'e bas."
• Ekran görüntüsü: Arayüz değiştiyse önce ve sonra.

Açıklamaya Closes #42 yazarsan, PR varsayılan branch'e (genelde main) merge edildiğinde GitHub o issue'yu otomatik kapatır. Fixes #42 ve Resolves #42 da aynı işi görür.

İş henüz bitmediyse ama erken geri bildirim istiyorsan PR'ı taslak (draft) olarak aç. Böylece "merge'e hazır değil ama yöne bir bakın" demiş olursun.

PR'ı küçük tut

Küçük PR'lar daha hızlı ve daha dikkatli review edilir, daha az çakışma çıkarır ve bir sorun olduğunda geri almak kolaydır. Google'ın herkese açık mühendislik rehberi de küçük değişiklikleri tam bu gerekçelerle önerir.

Pratik bir ölçü: Reviewer PR'ı tek oturuşta, yorulmadan okuyabilmeli. Okuyamıyorsa ikiye böl.

6. Review: almak ve vermek

Review bir sınav değil; kodun ikinci bir göz tarafından okunması.

Review alırken:

• Her yoruma cevap ver. Düzelttiysen "düzelttim" yaz, katılmıyorsan nedenini açıkla.
• Düzeltmeleri aynı branch'e yeni commit olarak push et; PR kendiliğinden güncellenir. Yeni PR açmana gerek yok.
• Yorumları kişisel alma. Yorum sana değil, koda yapılır.

Review verirken:

• Önce PR açıklamasını, sonra kodu oku. Neyi çözmeye çalıştığını bilmeden okuduğun kod sana yanlış görünebilir.
• Emir yerine soru kullan. "Bu değer null gelirse ne olur?" sorusu çoğu zaman "Bunu düzelt"ten daha çok şey öğretir.
• Zorunlu düzeltmeleri zevk meselelerinden ayır. Önemsiz bir öneriyi "küçük not:" diye başlatmak işe yarar.

7. main ilerlediyse branch'ini güncelle

Sen çalışırken başkalarının PR'ları merge edilir ve main ilerler. PR'ında çakışma (conflict) görünüyorsa branch'ini güncellemen gerekir:

git fetch origin
git rebase origin/main
# çakışma çıkarsa dosyaları düzelt, sonra:
git add <dosya>
git rebase --continue
git push --force-with-lease

Rebase, senin commit'lerini main'in en güncel halinin üstüne yeniden dizer. Geçmiş değiştiği için push'u zorlaman gerekir. --force-with-lease, uzaktaki branch'e senin haberin olmadan başka bir şey push edildiyse işlemi durdurur; düz --force bu kontrolü yapmaz.

Rebase sana yabancı geliyorsa git merge origin/main de iş görür; geçmişte fazladan bir merge commit'i oluşur, o kadar. Hangisini kullanacağınıza ekipçe önceden karar verin.

8. Merge ve temizlik

Onay geldiyse ve testler geçiyorsa PR'ı merge et. GitHub'da üç seçenek görürsün: normal merge, squash ve rebase. Squash, PR'daki küçük commit'leri main'de tek bir commit'e indirir; birçok ekip bu yüzden onu tercih eder. Hangisi olursa olsun, ekipte tek bir seçenekte anlaşmak önemli.

Sonra yerelde toparla:

git switch main
git pull
git branch -d 42-giris-eposta-dogrulama

Squash ile merge ettiysen Git, branch'in birleştiğini anlayamaz ve -d itiraz eder. PR'ın merge edildiğinden eminsen git branch -D ile sil.

Kuralları araca emanet et

"main'e doğrudan push yok" kuralını herkesin hatırlamasına güvenmek yerine GitHub'da branch korumasını (branch protection) aç. Merge'den önce belirli sayıda onaylı review ve testlerin geçmesini zorunlu tutabilirsin. Testleri her PR'da GitHub Actions gibi bir CI aracıyla çalıştırmak, reviewer'ı "bu kod derleniyor mu?" sorusundan da kurtarır.

re:make'in eğitim projesi emanet-app tam bu kurallarla yürüyor: main'e doğrudan push yok, PR'lar küçük, her PR'da GitHub Actions testleri çalıştırıyor ve main'e merge edilen kod otomatik olarak sunucuya deploy ediliyor. Yani orada merge düğmesine basmak "bu kod canlıya çıksın" demek.

Sık yapılan hatalar

• Yanlışlıkla main'de commit atmak. Henüz push etmediysen önce git status ile commit'lenmemiş değişiklik kalmadığından emin ol. Sonra git switch -c dogru-branch ile commit'lerini yeni bir branch'e al, git switch main ile geri dön ve git reset --hard origin/main ile yerel main'i uzaktakiyle eşitle. Commit'lerin yeni branch'te güvende kalır; ama reset --hard commit'lenmemiş değişiklikleri geri dönüşsüz siler.
• Tek PR'da üç işi birden yapmak. Review uzar, biri takılırsa hepsi bekler.
• Uzun yaşayan branch'ler. Bir branch ne kadar uzun açık kalırsa çakışmalar o kadar büyür. Küçük parçalarla sık merge et.
• Boş PR açıklaması. Reviewer'ı kodu tersine mühendislikle anlamaya zorlarsın.

Son söz

Bu akışı okumak beş dakika, alışmak birkaç hafta sürer. En hızlı yolu da gerçek bir ekipte, gerçek review'larla denemek. emanet-app'in nasıl kurgulandığını ve hangi kurallarla yürüdüğünü proje sayfasında görebilirsin.