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

> Git ile dallanma (branching) alışkanlıkları, merge stratejileri ve pull request ile izlenebilir bir değişiklik geçmişi kurmak.

- Yayın: 2017-12-03
- Kategori: Araçlar & Teknolojiler
- Etiketler: Git
- Okuma süresi: 3 dk okuma
- Kaynak: https://www.muhammetsafak.com.tr/blog/git-akisi-branch-merge-ve-pull-request-disiplini/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
[Git'i dosya yedeklemek için kullanmak](/blog/gite-gecis-ftp-ile-dosya-atmayi-birakmak) 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.

```bash
# 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.

```bash
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.

```bash
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:

```bash
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.