Git Dallanma Stratejileri: Feature Branch, GitFlow ve Trunk-Based

Git'in temel komutlarını öğrendikten sonra, ekip olarak çalışmaya başladığınızda karşınıza daha büyük bir soru çıkar: Dalları nasıl organize edeceğiz? Herkes doğrudan ana dala mı yazacak, yoksa her özellik ayrı bir dalda mı geliştirilecek? Sürümleri nasıl yöneteceğiz? Bu soruların cevabı, seçtiğiniz dallanma stratejisidir (branching strategy). Yanlış strateji, sürekli çakışmalara ve yayın gecikmelerine yol açarken, doğru strateji ekibin akışkan çalışmasını sağlar.

Bu yazıda en yaygın üç yaklaşımı ele alacağız: özellik dalları (feature branch), GitFlow ve gövde tabanlı geliştirme (trunk-based development). Her birinin güçlü ve zayıf yanları var; doğru seçim ekibin büyüklüğüne, yayın sıklığına ve olgunluğuna bağlı.

Dallanma Neden Gerekli?

Bir dal (branch), ana kod hattından ayrılan bağımsız bir geliştirme çizgisidir. Bir dal açtığınızda, ana koda dokunmadan üzerinde özgürce çalışabilir, denemeler yapabilirsiniz. İşiniz bittiğinde çalışmanızı ana hatta birleştirirsiniz (merge). Bu izolasyon sayesinde yarım kalmış bir özellik, üretimdeki kararlı kodu bozmaz.

git checkout -b ozellik/sepet-indirimi
# ... geliştirme yaparsınız ...
git commit -m "Sepet indirim kuralı eklendi"
git checkout main
git merge ozellik/sepet-indirimi

Özellik Dalı (Feature Branch) Yaklaşımı

En yaygın ve anlaşılması en kolay yöntemdir. Her yeni özellik veya hata düzeltmesi için ana daldan yeni bir dal açarsınız. Geliştirme tamamlanınca bir çekme isteği (pull request) açar, ekip inceler ve onaylanınca ana dala birleştirirsiniz.

• Artı: Her iş izole; yarım kalan özellik ana kodu etkilemez.
• Artı: Kod incelemesi doğal olarak akışa gömülüdür.
• Eksi: Dallar uzun süre açık kalırsa, birleştirme sırasında büyük çakışmalar çıkar.

Bu yaklaşımın altın kuralı, dalları kısa ömürlü tutmaktır. Bir dal ne kadar uzun süre ana koddan uzak kalırsa, tekrar birleştirmek o kadar acı verir.

GitFlow: Yapılandırılmış ama Ağır

GitFlow, birden fazla kalıcı dal öngören daha resmi bir modeldir. Tipik olarak şu dallar bulunur:

1. main: Yalnızca üretime çıkmış kararlı sürümler.
2. develop: Bir sonraki sürüm için toplanan çalışmalar.
3. feature/*: Tekil özellik dalları, develop'tan açılır.
4. release/*: Yayına hazırlık dalları.
5. hotfix/*: Üretimdeki acil düzeltmeler.

GitFlow, düzenli ve zamanlanmış sürümler çıkaran, sürüm numarası önemli olan ürünler için güçlüdür. Örneğin masaüstü uygulamaları veya kurumsal yazılımlar. Ancak sürekli teslimat (continuous delivery) yapan ekipler için fazla ağır kalır; çok sayıda dal ve birleştirme adımı yavaşlatıcı olabilir.

Strateji ne kadar karmaşıksa, ekibin ona uyması o kadar zordur. En iyi dallanma stratejisi, ekibinizin gerçekten disiplinle uygulayabileceği en basit olandır.

Trunk-Based Development: Hız İçin Sadelik

Gövde tabanlı geliştirme, tam tersi bir felsefeyi savunur: herkes tek bir ana dal (trunk) etrafında çalışır, dallar çok kısa ömürlüdür (birkaç saat ile bir gün). Değişiklikler günde birçok kez ana dala birleştirilir. Yarım kalan özellikler, kullanıcıya görünmeyecek şekilde özellik bayrakları (feature flags) arkasında saklanır.

Bu yaklaşım, güçlü otomatik testlere ve CI/CD altyapısına sahip olgun ekipler için idealdir. Çünkü sık birleştirme, ancak her birleştirmenin otomatik olarak test edilmesiyle güvenli hale gelir.

• Artı: Çakışmalar minimuma iner; herkes güncel kodla çalışır.
• Artı: Sürekli teslimatı doğal olarak destekler.
• Eksi: Sağlam test altyapısı olmadan riskli; bir hata hızla herkese yayılır.

Hangi Strateji Sizin İçin?

Doğru seçim ekibinizin durumuna bağlıdır:

• Küçük ekip, öğrenme aşamasındaysanız: Özellik dalı yaklaşımıyla başlayın.
• Zamanlanmış, sürümlü ürün geliştiriyorsanız: GitFlow disiplini işinizi kolaylaştırır.
• Sık yayın yapan, olgun ve otomasyona yatırım yapmış ekipseniz: Trunk-based en verimlisi.

Berasoft'ta müşteri projelerinin çoğunda özellik dalı yaklaşımını, güçlü kod incelemesiyle birleştirerek kullanırız. Sürüm sıklığı ve ekip olgunluğu arttıkça daha hafif modellere geçeriz. Projenizin geliştirme sürecini sağlam bir temele oturtmak için projenizi konuşalım.

Sonuç

Dallanma stratejisi, teknik bir tercih gibi görünse de aslında bir ekip kültürü meselesidir. Amaç, geliştiricilerin birbirini engellemeden hızla çalışabilmesi ve ana kodun her an kararlı kalmasıdır. Karmaşık bir strateji kağıt üzerinde ne kadar zarif olursa olsun, ekip ona uyamıyorsa işe yaramaz. En sade, ama disiplinle uygulanabilen yaklaşımı seçin; ekibiniz olgunlaştıkça stratejinizi de geliştirin. Doğru kurulmuş bir dallanma akışı, kaosu düzene, gecikmeleri de öngörülebilir teslimatlara dönüştürür.