Git akışı: branch, merge ve pull request disiplini

Git’i dosya yedeklemek için kullanmak ile Git’i değişiklik geçmişini anlamlı biçimde yönetmek için kullanmak arasında büyük bir fark var. İlk yıllarda git add -A, git commit -m "güncelleme", git push döngüsü yeterliydi. Ama birkaç ay sonra “bu satırı neden değiştirdim?” sorusunun yanıtını o commit geçmişinde bulamıyordum.

Branching ve commit disiplini, tek başına çalışırken de buna değer bir alışkanlık. Takımla çalışıldığında ise zorunluluk.

Dal stratejisi: ne zaman dal açmak gerekir?

Basit bir kural: main (ya da master) dalı her zaman çalışan, dağıtılabilir kodu temsil eder. Yeni bir şey denemek, bir hata düzeltmek veya bir özellik geliştirmek için ayrı dal açılır.

# Ana daldan yeni özellik dalı
git checkout main
git pull
git checkout -b feature/user-notifications

Dal isimlerini anlamlı yazmak önemli. fix/login-redirect-bug, feature/invoice-pdf, hotfix/payment-callback gibi isimler, dalın ne için açıldığını açıklamadan söylüyor.

Commit mesajları: neyi söylemeleri gerekiyor?

“Güncelleme”, “düzeltme”, “deneme” gibi mesajlar anlamsız. İyi bir commit mesajı şu soruyu yanıtlar: “Bu commit uygulanırsa ne olacak?”

Geniş kabul görmüş bir format:

feat: kullanıcı bildirim tercihlerini kaydetme özelliği eklendi

- Bildirim türleri (e-posta, SMS) ayrı ayrı açılıp kapatılabiliyor.
- Tercihler user_notification_settings tablosuna yazılıyor.

İlk satır kısa (50 karakter civarı), eylem kipinde (eklendi, düzeltildi, kaldırıldı). İkinci kısım isteğe bağlı ama “neden” sorusunu yanıtlıyorsa çok değerli.

feat, fix, refactor, docs, style gibi ön ekler kullanmak, geçmişi filtrelemeyi kolaylaştırıyor. Birlikte çalışılan bir projede herkesin aynı formatı kullandığında git log anlamlı bir belgeye dönüşüyor.

Merge stratejileri

Özellik dalını main’e birleştirirken birkaç seçenek var:

Merge commit: Dalın geçmişini ve birleşme noktasını korur. Büyük özellikler için tercih edilebilir.

git checkout main
git merge feature/user-notifications

Squash merge: Dalın tüm commit’lerini tek bir commit’e sıkıştırır. Küçük değişiklikler için geçmiş daha temiz kalır.

git merge --squash feature/user-notifications
git commit -m "feat: kullanıcı bildirim tercihleri eklendi"

Rebase: Dalın geçmişini main üzerine yeniden yazar, doğrusal bir geçmiş üretir. İyi sonuç verir ama paylaşılan dallarda dikkatli kullanılmalıdır.

Birini kesin “doğru” ilan etmek zor. Önemli olan tutarlılık: bir proje boyunca aynı stratejiyi kullanmak.

Pull request ile kod inceleme

GitHub veya GitLab üzerinde çalışıldığında, dalı doğrudan birleştirmek yerine pull request açmak alışkanlık haline geldi. Tek başına çalışırken bile bunu yapıyorum; çünkü kendi değişikliğime pull request üzerinden bakmak, controller içinde fark etmediğim şeyleri açık diff olarak görmemi sağlıyor.

Takımla çalışılırken:

1. Dal açılır, değişiklik yapılır.
2. Pull request açılır, ne yapıldığını açıklayan kısa bir açıklama yazılır.
3. Takım arkadaşı inceleyip onaylıyor (ya da yorum yapıyor).
4. main’e birleştirilir.

Bu döngü, “çalışıyor muydu bilmiyorum, push attım” yerine kasıtlı, gözden geçirilmiş değişiklikler üretiyor.

Geçmişi okumak

git log ve git blame araçlarını gerçekten kullanmak için anlamlı commit mesajları gerekiyor:

git log --oneline --graph   # Dallanma grafiğiyle kısa geçmiş
git log -p src/Payments/    # Belirli klasörde yapılan değişiklikler
git blame app/Models/Order.php  # Her satırı kimin, ne zaman değiştirdiği

git blame kötü bir isim — suçlama değil, “bu kodu kim neden yazdı?” sorusuna yanıt bulmak için kullanılıyor. Anlamlı commit mesajları varsa bu sorunun yanıtı commit mesajında zaten bulunuyor.

Git disiplini anlık bir getiri sunmuyor; ama üç ay sonra “bu değişikliği neden yapmıştım?” diye merak ettiğinizde ne kadar değerli olduğu anlaşılıyor.