Git Workflow: Feature Branch ve Pull Request Rehberi

İyi bir git workflow, bir ekibin koduna düzen getiren en ucuz yatırımdır. Tek başına çalışırken her şeyi doğrudan main dalına itmek sorun çıkarmaz; ama iki kişi aynı dosyaya dokunduğu an, kim neyi ne zaman değiştirdi sorusu cevapsız kalır. Feature branch (özellik dalı) ve pull request temelli akış, tam da bu kaosu önlemek için vardır: her iş kendi dalında gelişir, herkes değişikliği görmeden ana dal bozulmaz.

Bu yazıda Metin2 sunucu projelerinden Laravel web uygulamalarına kadar her tür ekipte işe yarayan, sade ama disiplinli bir akışı anlatıyorum. Amaç havalı komutlar ezberletmek değil; neyi neden yaptığını bilerek çalışmak.

Feature branch neden gerekli?

Ana dal (main ya da master) her zaman yayınlanabilir olmalıdır. Yani oradan çektiğin her hâli kurabilmeli, çalıştırabilmelisin. Bunu korumanın yolu, yarım kalmış işleri ana dala sokmamaktır. Her yeni özellik, hata düzeltmesi ya da deneme kendi dalında yaşar:

• Ana dal bozulmaz; üretim her an oradan deploy edilebilir.
• İki kişi paralel çalışsa bile birbirinin yarım kodunu görmez.
• Bir özellik iptal olursa, dalı silmek yeter; ana dalda iz kalmaz.
• Her dal, bağımsız olarak gözden geçirilebilir bir değişiklik kümesidir.

Dal açmak ve isimlendirme

Çalışmaya başlamadan önce ana dalı güncelle, sonra oradan yeni bir dal aç. Modern Git'te tek komutla yapılır:

git switch main
git pull --ff-only
git switch -c feature/kullanici-girisi

git switch -c, dalı oluşturup üstüne geçer; eski alışkanlıkla git checkout -b de aynı işi yapar. Dal adında tutarlı bir önek kullanmak, listeye baktığında işin türünü anında gösterir:

• feature/ — yeni özellik
• fix/ — hata düzeltme
• chore/ — bağımlılık, yapılandırma, temizlik
• refactor/ — davranışı değiştirmeyen iç düzenleme

Adı kısa ama anlamlı tut: fix/login-csrf, feature/odeme-webhooku gibi. İçinde issue numarası varsa onu da ekleyebilirsin: feature/142-pdf-export.

Commit disiplini

Bir commit, mantıklı tek bir değişikliği anlatmalı. "Her şeyi tek commit'te" ya da "her satır için ayrı commit" iki uçtaki hatadır. İyi bir mesaj ne değil neden sorusunu yanıtlar, çünkü "ne" zaten diff'te görünür:

git add app/Http/Controllers/AuthController.php
git commit -m "fix: oturum süresi dolunca 419 yerine login'e yönlendir"

Conventional Commits biçimi (feat:, fix:, chore:, docs:) hem okunaklıdır hem de otomatik changelog üretmeyi kolaylaştırır. İlk satırı 50–72 karakterde tut, gerekirse boş satırdan sonra ayrıntı yaz. Yarım kalmış, derlenmeyen kodu commit'lemekten kaçın; gerçekten ara kayıt gerekiyorsa git stash ya da işaretli bir "WIP" commit'i sonradan git rebase ile düzelt.

Dalı güncel tutmak: merge mi rebase mi?

Sen dalında çalışırken ana dal ilerler. Dalını güncellemenin iki yolu vardır. Merge, ana daldaki değişiklikleri dalına birleştirir ve birleştirme commit'i bırakır; geçmiş dürüsttür ama dallı budaklı görünür. Rebase, commit'lerini sanki en güncel ana dalın üstünden başlamış gibi yeniden oynatır; geçmiş düz ve okunaklı kalır.

git switch feature/kullanici-girisi
git fetch origin
git rebase origin/main

Pratik kural: henüz paylaşmadığın yerel dalında geçmişi düzeltmek için rebase rahatça kullanılır. Ama başkalarının da çektiği bir dalı rebase edip zorla itme (--force) işbirlikçilerin geçmişini bozar. O durumda --force-with-lease daha güvenlidir, çünkü senin son gördüğün halden beri bir değişiklik olduysa itmeyi reddeder.

Pull request: değişikliğin görünür hâli

Dalın hazır olunca uzağa it ve bir pull request (PR) aç:

git push -u origin feature/kullanici-girisi

PR, kodun birleşmeden önceki tartışma yeridir. İyi bir PR küçüktür — 400 satırın altındaki değişiklikler ciddi şekilde daha iyi incelenir, çünkü gözden geçiren kişi tamamını kafasında tutabilir. Açıklamasında şunlar olsun:

• Ne değişti ve neden: bir cümlelik bağlam çoğu zaman yeter.
• Nasıl test edildi: ekran görüntüsü, komut çıktısı ya da test adımı.
• İlgili issue bağlantısı (örn. Closes #142).

Otomatik kontroller (CI) — testler, linter, derleme — PR üstünde çalışmalı. Yeşil olmadan birleştirme. Bu, "bende çalışıyordu" sorununu büyük ölçüde ortadan kaldırır.

Code review ve birleştirme

İnceleme bir engel değil, ortak sahiplenmedir. Gözden geçiren kişi yalnızca hata aramaz; isimlendirme, kenar durumları ve daha basit bir çözümün mümkün olup olmadığını da sorar. Yorumlar koda değil soruna yöneliktir; "bunu neden böyle yaptın?" değil, "şu durumda ne olur?" tonu işbirliğini korur.

Onay alındığında birleştirme stratejisini seç:

• Squash merge: dalın tüm commit'lerini tek temiz commit'e indirger. Ana dal geçmişi okunaklı kalır; çoğu ekip için varsayılan budur.
• Merge commit: dalın tüm geçmişini korur. Büyük, anlamlı commit dizileri için iyidir.
• Rebase merge: commit'leri düz biçimde ana dala ekler, birleştirme commit'i bırakmaz.

Birleştikten sonra dalı sil — hem uzakta hem yerelde. Biriken ölü dallar, deponun gerçek durumunu okumayı zorlaştırır.

git switch main
git pull --ff-only
git branch -d feature/kullanici-girisi
git push origin --delete feature/kullanici-girisi

Sık Sorulan Sorular

Doğrudan main'e push etmek hiç doğru değil mi?

Tek kişilik küçük bir projede sorun değildir. Ama birden fazla kişi varsa ana dalı korumalı (protected branch) yap ve her değişikliği PR'dan geçir. Bu, hem inceleme hem de CI güvencesini zorunlu kılar.

Merge mi rebase mi kullanmalıyım?

İkisi de doğrudur, ekip kararıdır. Pratik bir denge: yerel dalını güncel tutmak ve commit'leri toplamak için rebase, PR'ı ana dala almak için squash merge. Paylaşılmış dalda asla zorla rebase itme.

PR ne kadar büyük olmalı?

Mümkün olduğunca küçük. Tek bir mantıksal işi kapsasın. Bir özellik büyükse, onu bağımsız olarak birleşebilen küçük PR'lara böl; incelemesi de, geri alması da kolaylaşır.

Ekibinizin git akışını oturtmakta mı zorlanıyorsunuz? Branch stratejisi, CI kurulumu ve code review kültürü konusunda yardıma ihtiyacınız varsa benimle iletişime geçin — projenize uygun, sade bir workflow birlikte kuralım.